From isis-wg-admin@spider.juniper.net Fri Feb 1 03:12:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01057 for ; Fri, 1 Feb 2002 03:12:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11850L19848; Fri, 1 Feb 2002 00:05:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1184WL19828 for ; Fri, 1 Feb 2002 00:04:32 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1189F610608; Fri, 1 Feb 2002 00:09:15 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g1189Fs64874; Fri, 1 Feb 2002 00:09:15 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200202010809.g1189Fs64874@cirrus.juniper.net> From: Dave Katz To: Ming.Chan@spirentcom.com CC: isis-wg@juniper.net, Ming.Chan@spirentcom.com In-reply-to: <8AC36D3167EED41184C800508BD9540501EE3DE9@apollo.adtech-inc.com> (Ming.Chan@spirentcom.com) Subject: Re: [Isis-wg] Ack'ing LSP on P2P References: <8AC36D3167EED41184C800508BD9540501EE3DE9@apollo.adtech-inc.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 1 Feb 2002 00:09:15 -0800 (PST) I've question that is related to the LSP ack mechanism based on what I observed from one of the vendor's router. If the router has two p2p interfaces, Int-A and Int-B, If on Int-A, a LSP (Seq # X) is rx and the router forwards the LSP to Int-B ( it is also expecting an Ack from the interface). Then, before an Ack is received on Int-B, a newer instance of the same LSP (Seq # Y > X) is received from Int-A again, On Int-A, the router sends out PSNP to ack the latest received LSP (Seq # Y > X) We observed that the router is still sending out LSP (Seq # X). (we purposely configure the other router that connected to Int-B to slow down on sending the Ack out). Shouldn't the next LSP sent out from Int-B be LSP (Seq #Y > X) ? This behavior is purely legal, so long as the higher sequenced LSP is eventually transmitted out of of Int-B. Without knowing more, it is hard to say whether this is just unlucky timing, or an implementation that would be really fun to put in a really big and unstable network (but then I have odd ideas about fun.) _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 1 03:17:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01689 for ; Fri, 1 Feb 2002 03:17:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g118AqL19882; Fri, 1 Feb 2002 00:10:52 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1184wL19833 for ; Fri, 1 Feb 2002 00:04:58 -0800 (PST) (envelope-from mshand@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g1189fc01268 for ; Fri, 1 Feb 2002 00:09:41 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 00:07:09 -0800 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4120.cisco.com [10.50.16.23]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA22646; Fri, 1 Feb 2002 08:07:41 GMT Message-Id: <4.3.2.7.2.20020201080015.03356000@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vijay Nath" From: mike shand Subject: Re: Re: [Isis-wg] ISIS routing on DA circuit Cc: isis-wg@juniper.net In-Reply-To: <20020201044704.13342.qmail@mailweb33.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Feb 2002 08:07:09.0656 (UTC) FILETIME=[726E4D80:01C1AAF7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 01 Feb 2002 08:07:15 +0000 At 04:47 01/02/2002 +0000, Vijay Nath wrote: >mike, > > when only manual route is the solution, what is need of router > sending those manual route to other routers.Even other routers too, have > manual information in their Reachable address prefix table, so it knows > where to send the pkt. No they don't. They may have reachable address prefixes for OTHER prefixes, but not (necessarily) for THIS prefix. Manual routing is NOT used (except under VERY strange circumstances, and then usually only as a result of misconfiguration) within the core of the network. It is used to hang reachable addresses as leaves off the the core tree. Often an RA will only appear hung off one router, although sometimes they will be "multi-homed". But the point is that you need the propagation of the routing information about them to make it all work. It may help you to think of reachable address prefixes in exactly the same way as IP subnets. In a sense they are "manual" routes since they are defined on the local interface. But you still need to propagate this information across the network so that other routers can route to them. Reachable addresses on DA circuits are similar >In sec 8.3.5 > >"There causes this information to be included in subsequently generated >LSPs as described in 7.3.3.2.Routeing PDUs (LSPs and SN PDUs) shall not be >sent on DA circuits" > >Two contradictory statements in a clause.Pl. explain on this. Not contradictory at all! The information is included in LSPs which are flooded, but NOT flooded over the DA circuits themselves. Mike >TIA, >V Nath > > > > >On Fri, 01 Feb 2002 mike shand wrote : > > At 10:18 29/01/2002 +0000, Vijay Nath wrote: > > > > > > >Hi All, > > > > > > As per spec 10589, DA circuits shall not send > > Hellos, LSPs and > > > SNPs.Then how dynamic routing is achieved ??. > > >or it is not possible (dynamic routing) in DA > > circuits??. > > > > It's not possible. A DA circuit has a reachable address > > prefix (aka manual > > route) attached to it, and the circuit is only brought > > up when there is > > traffic to that destination. The manual route is of > > course advertised in > > LSPs and propagated to other routers so that they know > > where to send the > > traffic. It was primarily designed for use with X.25 > > SVCs(which tells you > > how old it is), where you only want to pay for a > > virtual circuit when you > > have traffic. > > > > Mike > > > > > > > > >TIA, > > >V Nath > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 1 04:06:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06000 for ; Fri, 1 Feb 2002 04:06:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11907L20161; Fri, 1 Feb 2002 01:00:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g118lXL20091 for ; Fri, 1 Feb 2002 00:47:33 -0800 (PST) (envelope-from mshand@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g118qGc01910 for ; Fri, 1 Feb 2002 00:52:16 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 00:51:13 -0800 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4120.cisco.com [10.50.16.23]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA23564; Fri, 1 Feb 2002 08:51:46 GMT Message-Id: <4.3.2.7.2.20020201084921.03315768@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vijay Nath" From: mike shand Subject: Re: [Isis-wg] ISIS routing on DA circuit Cc: isis-wg@juniper.net In-Reply-To: <20020201084817.21555.qmail@mailFA3.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Feb 2002 08:51:14.0156 (UTC) FILETIME=[9AACFAC0:01C1AAFD] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 01 Feb 2002 08:51:03 +0000 At 08:48 01/02/2002 +0000, Vijay Nath wrote: > > > > >In sec 8.3.5 > > > > > >"There causes this information to be included in > > subsequently generated > > >LSPs as described in 7.3.3.2.Routeing PDUs (LSPs and > > SN PDUs) shall not be > > >sent on DA circuits" > > > > > >Two contradictory statements in a clause.Pl. explain > > on this. > > > > Not contradictory at all! The information is included > > in LSPs which are > > flooded, but NOT flooded over the DA circuits > > themselves. > > > >I Gotcha.But if a router have only DA Ciruits (for argument sake), how the >RA are flooded??.. They are not! There's not much point in running IS-IS if all you have are DA circuits! Mike > > Mike > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 1 04:11:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06675 for ; Fri, 1 Feb 2002 04:11:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1194WL20193; Fri, 1 Feb 2002 01:04:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g118ncL20102 for ; Fri, 1 Feb 2002 00:49:38 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g118sLc01929 for ; Fri, 1 Feb 2002 00:54:21 -0800 (PST) X-JNPR-Received-From: outside Received: from mailFA3.rediffmail.com ([202.54.124.148]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 00:46:43 -0800 Received: (qmail 21556 invoked by uid 510); 1 Feb 2002 08:48:17 -0000 Message-ID: <20020201084817.21555.qmail@mailFA3.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 01 Feb 2002 08:48:17 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: "mike shand" Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] ISIS routing on DA circuit Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 01 Feb 2002 08:46:43.0749 (UTC) FILETIME=[F9802550:01C1AAFC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g118ncL20103 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 1 Feb 2002 08:48:17 -0000 Content-Transfer-Encoding: 8bit > > >In sec 8.3.5 > > > >"There causes this information to be included in > subsequently generated > >LSPs as described in 7.3.3.2.Routeing PDUs (LSPs and > SN PDUs) shall not be > >sent on DA circuits" > > > >Two contradictory statements in a clause.Pl. explain > on this. > > Not contradictory at all! The information is included > in LSPs which are > flooded, but NOT flooded over the DA circuits > themselves. > I Gotcha.But if a router have only DA Ciruits (for argument sake), how the RA are flooded??.. > Mike > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 1 09:48:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24501 for ; Fri, 1 Feb 2002 09:48:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11Ee7L22253; Fri, 1 Feb 2002 06:40:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11EOYL22170 for ; Fri, 1 Feb 2002 06:24:34 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g11ETJc07871 for ; Fri, 1 Feb 2002 06:29:19 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 06:23:34 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g11EOON27901; Fri, 1 Feb 2002 09:24:24 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (sjc-vpn1-388.cisco.com [10.21.97.132]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAQ90246; Fri, 1 Feb 2002 09:24:07 -0500 (EST) Message-Id: <4.3.2.7.2.20020201090235.03bf6c30@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vijay Nath" From: Jeff Learman Subject: Re: Re: [Isis-wg] ISIS routing on DA circuit Cc: "mike shand" , isis-wg@juniper.net In-Reply-To: <20020201044704.13342.qmail@mailweb33.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 01 Feb 2002 14:23:34.0921 (UTC) FILETIME=[084C3F90:01C1AB2C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 01 Feb 2002 09:03:45 -0500 It's much better to manually configure a route at one location (at the "source" of the route) and let IS-IS propagate that route to all routers, than to have to manually configure the same route on all routers. Regards, Jeff At 11:47 PM 1/31/2002, Vijay Nath wrote: >mike, > > when only manual route is the solution, what is need of router sending those manual route to other routers.Even other routers too, have manual information in their Reachable address prefix table, so it knows where to send the pkt. > >In sec 8.3.5 > >"There causes this information to be included in subsequently generated LSPs as described in 7.3.3.2.Routeing PDUs (LSPs and SN PDUs) shall not be sent on DA circuits" > >Two contradictory statements in a clause.Pl. explain on this. > >TIA, >V Nath > > > > >On Fri, 01 Feb 2002 mike shand wrote : >> At 10:18 29/01/2002 +0000, Vijay Nath wrote: >> >> >> >Hi All, >> > >> > As per spec 10589, DA circuits shall not send >> Hellos, LSPs and >> > SNPs.Then how dynamic routing is achieved ??. >> >or it is not possible (dynamic routing) in DA >> circuits??. >> >> It's not possible. A DA circuit has a reachable address >> prefix (aka manual >> route) attached to it, and the circuit is only brought >> up when there is >> traffic to that destination. The manual route is of >> course advertised in >> LSPs and propagated to other routers so that they know >> where to send the >> traffic. It was primarily designed for use with X.25 >> SVCs(which tells you >> how old it is), where you only want to pay for a >> virtual circuit when you >> have traffic. >> >> Mike >> >> >> >> >TIA, >> >V Nath >> > >> >_______________________________________________ >> >Isis-wg mailing list - Isis-wg@external.juniper.net >> >http://external.juniper.net/mailman/listinfo/isis-wg >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:25:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02599 for ; Sat, 2 Feb 2002 07:25:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CI6L30810; Sat, 2 Feb 2002 04:18:06 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11EKqL22151 for ; Fri, 1 Feb 2002 06:20:52 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g11EPbc07826 for ; Fri, 1 Feb 2002 06:25:37 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 06:23:35 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g11EOPv27905; Fri, 1 Feb 2002 09:24:26 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (sjc-vpn1-388.cisco.com [10.21.97.132]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAQ90248; Fri, 1 Feb 2002 09:24:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020201091329.01d351c8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vijay Nath" From: Jeff Learman Subject: Re: Re: [Isis-wg] ISIS routing on DA circuit Cc: isis-wg@juniper.net In-Reply-To: <4.3.2.7.2.20020201080015.03356000@jaws.cisco.com> References: <20020201044704.13342.qmail@mailweb33.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 01 Feb 2002 14:23:35.0484 (UTC) FILETIME=[08A227C0:01C1AB2C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 01 Feb 2002 09:23:55 -0500 Another way of looking at this is, when you do manually configure a route, you don't want to have to manually configure that route on every router, do you? Of course not. You only configure it at the point of origin, and IS-IS disseminates it throughout the rest of the area/domain. Unfortunately, you can't use it to flood this information across a DA circuit. I think the idea was that in any sizeable network, there would be enough chatter on any link where IS-IS was run that it wouldn't make any sense for it to be a DA circuit. Also, when the link connects significant portions of a network, it would normally have enough traffic to justify a statically assigned circuit. So, while I said "unfortunate", I haven't seen any cases where another method didn't work better (e.g., static routing, BGP). Regards, Jeff At 03:07 AM 2/1/2002, mike shand wrote: >At 04:47 01/02/2002 +0000, Vijay Nath wrote: > >>mike, >> >> when only manual route is the solution, what is need of router sending those manual route to other routers.Even other routers too, have manual information in their Reachable address prefix table, so it knows where to send the pkt. > >No they don't. They may have reachable address prefixes for OTHER prefixes, but not (necessarily) for THIS prefix. Manual routing is NOT used (except under VERY strange circumstances, and then usually only as a result of misconfiguration) within the core of the network. It is used to hang reachable addresses as leaves off the the core tree. Often an RA will only appear hung off one router, although sometimes they will be "multi-homed". But the point is that you need the propagation of the routing information about them to make it all work. > >It may help you to think of reachable address prefixes in exactly the same way as IP subnets. In a sense they are "manual" routes since they are defined on the local interface. But you still need to propagate this information across the network so that other routers can route to them. > >Reachable addresses on DA circuits are similar > > >>In sec 8.3.5 >> >>"There causes this information to be included in subsequently generated LSPs as described in 7.3.3.2.Routeing PDUs (LSPs and SN PDUs) shall not be sent on DA circuits" >> >>Two contradictory statements in a clause.Pl. explain on this. > >Not contradictory at all! The information is included in LSPs which are flooded, but NOT flooded over the DA circuits themselves. > > Mike > > > >>TIA, >>V Nath >> >> >> >> >>On Fri, 01 Feb 2002 mike shand wrote : >>> At 10:18 29/01/2002 +0000, Vijay Nath wrote: >>> >>> >>> >Hi All, >>> > >>> > As per spec 10589, DA circuits shall not send >>> Hellos, LSPs and >>> > SNPs.Then how dynamic routing is achieved ??. >>> >or it is not possible (dynamic routing) in DA >>> circuits??. >>> >>> It's not possible. A DA circuit has a reachable address >>> prefix (aka manual >>> route) attached to it, and the circuit is only brought >>> up when there is >>> traffic to that destination. The manual route is of >>> course advertised in >>> LSPs and propagated to other routers so that they know >>> where to send the >>> traffic. It was primarily designed for use with X.25 >>> SVCs(which tells you >>> how old it is), where you only want to pay for a >>> virtual circuit when you >>> have traffic. >>> >>> Mike >>> >>> >>> >>> >TIA, >>> >V Nath >>> > >>> >_______________________________________________ >>> >Isis-wg mailing list - Isis-wg@external.juniper.net >>> >http://external.juniper.net/mailman/listinfo/isis-wg >>> >>> _______________________________________________ >>> Isis-wg mailing list - Isis-wg@external.juniper.net >>> http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:27:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02626 for ; Sat, 2 Feb 2002 07:27:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CLHL30899; Sat, 2 Feb 2002 04:21:18 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11FoKL22621 for ; Fri, 1 Feb 2002 07:50:20 -0800 (PST) (envelope-from prz@redback.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g11Ft5c10237; Fri, 1 Feb 2002 07:55:05 -0800 (PST) X-JNPR-Received-From: outside Received: from mta7.pltn13.pbi.net ([64.164.98.8]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 07:53:42 -0800 Received: from redback.com ([63.200.49.47]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQV00IA32UJWP@mta7.pltn13.pbi.net>; Fri, 01 Feb 2002 07:54:19 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Ack'ing LSP on P2P To: Dave Katz Cc: Ming.Chan@spirentcom.com, isis-wg@juniper.net Message-id: <3C5A9B70.375D93BB@redback.com> 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: <8AC36D3167EED41184C800508BD9540501EE3DE9@apollo.adtech-inc.com> <200202010809.g1189Fs64874@cirrus.juniper.net> X-OriginalArrivalTime: 01 Feb 2002 15:53:42.0125 (UTC) FILETIME=[9F3E19D0:01C1AB38] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 01 Feb 2002 05:43:13 -0800 Content-Transfer-Encoding: 7BIT Dave Katz wrote: > I've question that is related to the LSP ack mechanism based on what > I observed from one of the vendor's router. > > If the router has two p2p interfaces, Int-A and Int-B, > > If on Int-A, a LSP (Seq # X) is rx and the router forwards the LSP > to Int-B ( it is also expecting an Ack from the interface). > > Then, before an Ack is received on Int-B, a newer instance of the > same LSP (Seq # Y > X) is received from Int-A again, > > On Int-A, the router sends out PSNP to ack the latest received LSP > (Seq # Y > X) > > We observed that the router is still sending out LSP (Seq # X). (we > purposely configure the other router that connected to Int-B to slow down on > sending the Ack out). > > Shouldn't the next LSP sent out from Int-B be LSP (Seq #Y > X) ? > > This behavior is purely legal, so long as the higher sequenced LSP is > eventually transmitted out of of Int-B. Without knowing more, it is > hard to say whether this is just unlucky timing, or an implementation > that would be really fun to put in a really big and unstable network > (but then I have odd ideas about fun.) > Since you're going the 'how-do-we-implement-s....' path [ where s.... stands for software of course ;-) ] let's have it albeit we should not let the list deteriorate into wall-of-flames about an implementation being better than the other. And the moment any vendors (except predominant ones which don't care ;-) get insulted by name, we'll have to call timeout of course! The only reason I saw such behavior recently was when there was _plenty_ of interface and plenty of LSPs to send around or shortly Heavy Load (TM). Basically what was happening was that the LSPs were generated as bits and bytes and buffered on outgoing interface buffers, I/O cards, wherever the I/O system had buffers. Then it's kind of hard to jump in and say, 'oh, you kernel there, go quickly scan all your mbufs and replace anything that was X with Y'. But within the protocol code it's kind of trivial to keep the pointer from the re-transmit interface queue (if one chooses that architecture, I normally don't like it too much for scaling) and hten the pointer points to version Y next time it gets to transmission automatically ( I assume nobody keep X and Y at the same time in the database, that would be too brain-twisted). Or if one chooses to keep interfaces to be transmitted/retransmitted on in LSP, same thing applies. But maybe and only maybe, somebody keeps _full_ copies of LSPs on the re-/transmit queues which is positively scary [my first OSPF attempt ever was doing that ;-) since I was tired of chasing the 'I had a pointer on retransmission list and for some reason the LSP went away and my pointer dangled' problems. But then, IP was just a freebie hack, life was good and I didn't have to scale ;-) ] So if there is no load and things go really slowly and the described obvious naivety is not, we may learn something from the reasoning why such a thing shall happen. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:28:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02644 for ; Sat, 2 Feb 2002 07:28:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CLPL30945; Sat, 2 Feb 2002 04:21:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11IVNL23320 for ; Fri, 1 Feb 2002 10:31:23 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g11Ia4631654; Fri, 1 Feb 2002 10:36:04 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g11Ia4466517; Fri, 1 Feb 2002 10:36:04 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200202011836.g11Ia4466517@cirrus.juniper.net> From: Dave Katz To: prz@redback.com CC: Ming.Chan@spirentcom.com, isis-wg@juniper.net In-reply-to: <3C5A9B70.375D93BB@redback.com> (message from Tony Przygienda on Fri, 01 Feb 2002 05:43:13 -0800) Subject: Re: [Isis-wg] Ack'ing LSP on P2P References: <8AC36D3167EED41184C800508BD9540501EE3DE9@apollo.adtech-inc.com> <200202010809.g1189Fs64874@cirrus.juniper.net> <3C5A9B70.375D93BB@redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 1 Feb 2002 10:36:04 -0800 (PST) Pretty much what I said. ;-) --Dave Since you're going the 'how-do-we-implement-s....' path [ where s.... stands for software of course ;-) ] let's have it albeit we should not let the list deteriorate into wall-of-flames about an implementation being better than the other. And the moment any vendors (except predominant ones which don't care ;-) get insulted by name, we'll have to call timeout of course! The only reason I saw such behavior recently was when there was _plenty_ of interface and plenty of LSPs to send around or shortly Heavy Load (TM). Basically what was happening was that the LSPs were generated as bits and bytes and buffered on outgoing interface buffers, I/O cards, wherever the I/O system had buffers. Then it's kind of hard to jump in and say, 'oh, you kernel there, go quickly scan all your mbufs and replace anything that was X with Y'. But within the protocol code it's kind of trivial to keep the pointer from the re-transmit interface queue (if one chooses that architecture, I normally don't like it too much for scaling) and hten the pointer points to version Y next time it gets to transmission automatically ( I assume nobody keep X and Y at the same time in the database, that would be too brain-twisted). Or if one chooses to keep interfaces to be transmitted/retransmitted on in LSP, same thing applies. But maybe and only maybe, somebody keeps _full_ copies of LSPs on the re-/transmit queues which is positively scary [my first OSPF attempt ever was doing that ;-) since I was tired of chasing the 'I had a pointer on retransmission list and for some reason the LSP went away and my pointer dangled' problems. But then, IP was just a freebie hack, life was good and I didn't have to scale ;-) ] So if there is no load and things go really slowly and the described obvious naivety is not, we may learn something from the reasoning why such a thing shall happen. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:28:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02643 for ; Sat, 2 Feb 2002 07:28:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CLLL30925; Sat, 2 Feb 2002 04:21:21 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rchss002.chiaro.com (rchss002.chiaro.com [63.88.196.82]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g11HiFL23113 for ; Fri, 1 Feb 2002 09:44:15 -0800 (PST) (envelope-from lliu@chiaro.com) Received: (qmail 26948 invoked from network); 1 Feb 2002 17:40:08 -0000 Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82) by rchss002.chiaro.com with SMTP; 1 Feb 2002 17:40:08 -0000 Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 11:32:11 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A50701C4BF4E@MAIL> From: Laura Liu To: "'Jeff Parker'" Cc: "'IS-IS-WG (E-mail)'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary" Subject: [Isis-wg] Questions about isis mib Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 1 Feb 2002 11:32:10 -0600 --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Jeff, I am not clear why we need the isisCircIndex in isisIPRATable. IP Reachable Address (either static, or direct connected, or redistributed from other routing protocol) is per isis router based, not a isis circuit based. Any light are appreciated. Laura isisIPRATable OBJECT-TYPE SYNTAX SEQUENCE OF IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of IP Reachable Addresses to networks, subnetworks or hosts either manually configured or learned from another protocol." ::= { isisIPReachAddr 1 } isisIPRAEntry OBJECT-TYPE SYNTAX IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines an IP Reachable Address to a network, subnetwork or host." INDEX { isisSysInstance, isisCircIndex, isisIPRAType, isisIPRAIndex } ::= { isisIPRATable 1 } --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:28:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02665 for ; Sat, 2 Feb 2002 07:28:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CLSL30961; Sat, 2 Feb 2002 04:21:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g11L7oL24139 for ; Fri, 1 Feb 2002 13:07:50 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Laura Liu'" Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Questions about isis mib Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 1 Feb 2002 16:12:29 -0500 > Hi Jeff, > > I am not clear why we need the isisCircIndex in > isisIPRATable. IP Reachable Address (either > static, or direct connected, or redistributed > from other routing protocol) is per isis router > based, not a isis circuit based. > > Any light are appreciated. > > Laura Laura - You are right that other systems do not need to know this information. However, SNMP is used to manage the router. If you are to tell ISIS to add this address, you want the protocol where to send the packets with that address. - jeff parker > isisIPRATable OBJECT-TYPE > SYNTAX SEQUENCE OF IsisIPRAEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The table of IP Reachable Addresses to networks, > subnetworks or hosts either manually configured or > learned from another protocol." > ::= { isisIPReachAddr 1 } > > isisIPRAEntry OBJECT-TYPE > SYNTAX IsisIPRAEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry defines an IP Reachable Address to a network, > subnetwork or host." > INDEX { isisSysInstance, > isisCircIndex, > isisIPRAType, > isisIPRAIndex } > ::= { isisIPRATable 1 } > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:28:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02666 for ; Sat, 2 Feb 2002 07:28:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CLbL31009; Sat, 2 Feb 2002 04:21:37 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g122HOL25453 for ; Fri, 1 Feb 2002 18:17:24 -0800 (PST) (envelope-from cast@allegronetworks.com) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 18:21:16 -0800 Message-ID: From: Neal Castagnoli To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Potential for impossible state in the 3-way text Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 1 Feb 2002 18:21:13 -0800 The current 3-way text states: Neighbor System ID if known (zero to eight octets) Neighbor Extended Local Circuit ID (four octets, if Neighbor System ID is present) It is possible to know the Neighbor System ID, but not know the Neighbor Extended Local Circuit ID, and in that event you are commanded to put information into the packet you don't have (at least one of the common implementations sends only the state, and it is also possible the other side may not support 3-way). Furthermore, if you know the neighbor extended local circuit ID, you'll always know the neighbor system ID, and so "if Neighbor System ID is present" is superfluous. It seems to me that the encoding rules should state Neighbor System ID if Neighbor Extended Local Circuit ID known (six octets) Neighbor Extended Local Circuit ID if known (four octets) -or- Neighbor System ID if known (six octets) Neighbor Extended Local Circuit ID if known (four octets) The former has the advantage that there are less encoding formats. --Neal Castagnoli Allegro Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:28:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02687 for ; Sat, 2 Feb 2002 07:28:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CLVL30977; Sat, 2 Feb 2002 04:21:31 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rchss002.chiaro.com (rchss002.chiaro.com [63.88.196.82]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g11MRdL24478 for ; Fri, 1 Feb 2002 14:27:40 -0800 (PST) (envelope-from lliu@chiaro.com) Received: (qmail 708 invoked from network); 1 Feb 2002 22:29:25 -0000 Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82) by rchss002.chiaro.com with SMTP; 1 Feb 2002 22:29:25 -0000 Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 16:31:52 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A50701C4C081@MAIL> From: Laura Liu To: Jeff Parker , Laura Liu Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary" Subject: [Isis-wg] RE: Questions about isis mib Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 1 Feb 2002 16:31:51 -0600 --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Jeff, You mean the isisCircIndex here reports the interface to which next hopw is connected. Does it consider to be an attribute of IPRA? If we use isisCircIndex before the IPRAIndex, it will display the IP reachable routes grouped by its next hop interface. It looks odd to me, because this table is IPRATable not under a circuit table. I would prefer we add an entry like isisIPRANextHop (interface name or IP net address as value) and remove isisCircIndex in oid index. what do you think? best regards, Laura > Hi Jeff, > > I am not clear why we need the isisCircIndex in > isisIPRATable. IP Reachable Address (either > static, or direct connected, or redistributed > from other routing protocol) is per isis router > based, not a isis circuit based. > Any light are appreciated. > > Laura Laura - You are right that other systems do not need to know this information. However, SNMP is used to manage the router. If you are to tell ISIS to add this address, you want the protocol where to send the packets with that address. - jeff parker > isisIPRATable OBJECT-TYPE > SYNTAX SEQUENCE OF IsisIPRAEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The table of IP Reachable Addresses to networks, > subnetworks or hosts either manually configured or > learned from another protocol." > ::= { isisIPReachAddr 1 } > > isisIPRAEntry OBJECT-TYPE > SYNTAX IsisIPRAEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry defines an IP Reachable Address to a network, > subnetwork or host." > INDEX { isisSysInstance, > isisCircIndex, > isisIPRAType, > isisIPRAIndex } > ::= { isisIPRATable 1 } > --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 2 07:28:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02700 for ; Sat, 2 Feb 2002 07:28:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g12CLYL30993; Sat, 2 Feb 2002 04:21:34 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rchss002.chiaro.com (rchss002.chiaro.com [63.88.196.82]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g11NG4L24687 for ; Fri, 1 Feb 2002 15:16:04 -0800 (PST) (envelope-from lliu@chiaro.com) Received: (qmail 1300 invoked from network); 1 Feb 2002 23:17:49 -0000 Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82) by rchss002.chiaro.com with SMTP; 1 Feb 2002 23:17:49 -0000 Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 17:20:20 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A50701C4C0A2@MAIL> From: Laura Liu To: Jeff Parker Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary" Subject: [Isis-wg] RE: Questions about isis mib Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 1 Feb 2002 17:20:19 -0600 --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" It seems isisIPRAAddress obj will give the next hop info. isisIPRASNPAAddress OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The SNPA Address to which a PDU may be forwarded in order to reach a destination which matches this IP Reachable Address. This object follows the manualOrAutomatic behavior." DEFVAL { ''H } ::= { isisIPRAEntry 10 } Would this be sufficient to know where to send the packets with IPRAddress? Laura -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Friday, February 01, 2002 3:12 PM To: 'Laura Liu' Cc: IS-IS-WG (E-mail) Subject: RE: Questions about isis mib > Hi Jeff, > > I am not clear why we need the isisCircIndex in > isisIPRATable. IP Reachable Address (either > static, or direct connected, or redistributed > from other routing protocol) is per isis router > based, not a isis circuit based. > > Any light are appreciated. > > Laura Laura - You are right that other systems do not need to know this information. However, SNMP is used to manage the router. If you are to tell ISIS to add this address, you want the protocol where to send the packets with that address. - jeff parker > isisIPRATable OBJECT-TYPE > SYNTAX SEQUENCE OF IsisIPRAEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The table of IP Reachable Addresses to networks, > subnetworks or hosts either manually configured or > learned from another protocol." > ::= { isisIPReachAddr 1 } > > isisIPRAEntry OBJECT-TYPE > SYNTAX IsisIPRAEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry defines an IP Reachable Address to a network, > subnetwork or host." > INDEX { isisSysInstance, > isisCircIndex, > isisIPRAType, > isisIPRAIndex } > ::= { isisIPRATable 1 } > --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 3 09:48:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25735 for ; Sun, 3 Feb 2002 09:48:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g13Ee0L37890; Sun, 3 Feb 2002 06:40:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from venus.postmark.net (venus.postmark.net [207.244.122.71]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g13EdvL37875 for ; Sun, 3 Feb 2002 06:39:57 -0800 (PST) (envelope-from Chaitanya77@postmark.net) Received: (qmail 20374 invoked by uid 501); 3 Feb 2002 15:51:26 -0000 Message-ID: <20020203155126.20373.qmail@venus.postmark.net> Received: from 203.200.20.226 by www.postmark.net with HTTP; 03 Feb 2002 15:51:26 -0000 Mime-Version: 1.0 From: Chaitanya Huilgol To: isis-wg@spider.juniper.net Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] LSP expiration sync Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 03 Feb 2002 15:51:26 +0000 hi can anyone give me reason for the following: ref10589: 7.3.16.4 LSP expiration synchronisation b) If an LSP from S is in the database, then 1) If the received LSP is newer than the one in the database (i.e. received LSP has higher sequence number, or same sequence number and database LSP has nonzero Remaining Lifetime) the IS shall: i) overwrite the database LSP with the received LSP, and note the time at which the zero Remaining Lifetime LSP was received, so that after ZeroAgeLifetime has elapsed, that LSP can be purged from the database, ii) set SRMflag for that LSP for all circuits, iii) clear SSNflag for that LSP for all circuits. ...normally we clear the SRM on the Received CKT set it on all other circuits set the SSN on the received circuit if the circuit is P2P. why are we sending the same LSP back on the same LINK it came from? we could have simply ack it, now the IS on the other side has to ack it thanks in advance --------------------------------------------- Chaitanya Huilgol. Chaitanya77@postmark.net --------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 3 14:34:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29161 for ; Sun, 3 Feb 2002 14:34:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g13JR1L39053; Sun, 3 Feb 2002 11:27:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g13JQwL39041 for ; Sun, 3 Feb 2002 11:26:58 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA25561; Sun, 3 Feb 2002 11:31:28 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Feb 2002 11:31:28 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F777@avalon.pluris.com> From: Les Ginsberg To: "'Chaitanya Huilgol '" , "'isis-wg@spider.juniper.net '" Subject: RE: [Isis-wg] LSP expiration sync MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 3 Feb 2002 11:31:25 -0800 This is another instance of a defect which was detected many years ago and corrected, but not published outside of internal ISO circles. The corrected text has been included in the ISO 10589:2001 Revision 2 draft and reads: b) If an LSP from S is in the database, then 1) If the received LSP is newer than the one in the data-base (i.e. received LSP has higher sequence number, or same sequence number and database LSP has non-zero Remaining Lifetime) the IS shall: i. Store the new LSP in the database, overwriting the existing database LSP for that source (if any) with the received LSP. ii. Set SRMflag for that LSP for all circuits other then C. iii. Clear the SRMflag for that LSP for C. iv. If C is a non-broadcast circuit, set SSNflag for that LSP for C. v. clear SSNflag for that LSP for all circuits associated with that linkage other than C. (The following recorded message shall be repeated from time to time as necessary) I highly recommend people use the 2001 draft as an updated reference. (ftp.cisco.com/pub/rfc/ISO/ISO10589v2-2001-07-04.pdf) Les -----Original Message----- From: Chaitanya Huilgol To: isis-wg@spider.juniper.net Sent: 2/3/02 7:51 AM Subject: [Isis-wg] LSP expiration sync hi can anyone give me reason for the following: ref10589: 7.3.16.4 LSP expiration synchronisation b) If an LSP from S is in the database, then 1) If the received LSP is newer than the one in the database (i.e. received LSP has higher sequence number, or same sequence number and database LSP has nonzero Remaining Lifetime) the IS shall: i) overwrite the database LSP with the received LSP, and note the time at which the zero Remaining Lifetime LSP was received, so that after ZeroAgeLifetime has elapsed, that LSP can be purged from the database, ii) set SRMflag for that LSP for all circuits, iii) clear SSNflag for that LSP for all circuits. ...normally we clear the SRM on the Received CKT set it on all other circuits set the SSN on the received circuit if the circuit is P2P. why are we sending the same LSP back on the same LINK it came from? we could have simply ack it, now the IS on the other side has to ack it thanks in advance --------------------------------------------- Chaitanya Huilgol. Chaitanya77@postmark.net --------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 3 15:04:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29377 for ; Sun, 3 Feb 2002 15:04:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g13Jw0L39219; Sun, 3 Feb 2002 11:58:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g13JvOL39207 for ; Sun, 3 Feb 2002 11:57:24 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA26138; Sun, 3 Feb 2002 12:02:22 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Feb 2002 12:02:22 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F778@avalon.pluris.com> From: Les Ginsberg To: "'Neal Castagnoli '" , "''isis-wg@spider.juniper.net' '" Subject: RE: [Isis-wg] Potential for impossible state in the 3-way text MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 3 Feb 2002 12:02:21 -0800 In general I agree with Neal's comments. It can be debated (not too vehemently I think) that there may still be some value in sending neighbor System ID even when you don't know neighbor extended circuit ID just to catch the case where due to physical layer changes you are suddenly connected to "somebody else". This would only be of value if the neighbor sends only the 1 byte state value in its 3 way option but supports on reception the full 17 byte option. Possible I suppose, but seems not very likely. But if we stick to the tried and true mantra of being generous in what we receive, then there seems no reason to disallow this form. I would therefore suggest a slightly modified version of Neal's second proposal: Neighbor System ID if known (0-8 octets) Neighbor Extended Local Circuit ID if known (four octets) (BTW - Neal I assume your specifying "6" as the system ID length was an unintentional slip due to common practice.) Les -----Original Message----- From: Neal Castagnoli To: 'isis-wg@spider.juniper.net' Sent: 2/1/02 6:21 PM Subject: [Isis-wg] Potential for impossible state in the 3-way text The current 3-way text states: Neighbor System ID if known (zero to eight octets) Neighbor Extended Local Circuit ID (four octets, if Neighbor System ID is present) It is possible to know the Neighbor System ID, but not know the Neighbor Extended Local Circuit ID, and in that event you are commanded to put information into the packet you don't have (at least one of the common implementations sends only the state, and it is also possible the other side may not support 3-way). Furthermore, if you know the neighbor extended local circuit ID, you'll always know the neighbor system ID, and so "if Neighbor System ID is present" is superfluous. It seems to me that the encoding rules should state Neighbor System ID if Neighbor Extended Local Circuit ID known (six octets) Neighbor Extended Local Circuit ID if known (four octets) -or- Neighbor System ID if known (six octets) Neighbor Extended Local Circuit ID if known (four octets) The former has the advantage that there are less encoding formats. --Neal Castagnoli Allegro Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 4 01:56:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06899 for ; Mon, 4 Feb 2002 01:56:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g146n0L41740; Sun, 3 Feb 2002 22:49:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g146mQL41728 for ; Sun, 3 Feb 2002 22:48:26 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g146rSc59619 for ; Sun, 3 Feb 2002 22:53:28 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb26.rediffmail.com ([203.199.83.30]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Feb 2002 22:50:50 -0800 Received: (qmail 23110 invoked by uid 510); 4 Feb 2002 06:52:02 -0000 Message-ID: <20020204065202.23109.qmail@mailweb26.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 04 Feb 2002 06:52:02 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: "Jeff Learman" Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] ISIS routing on DA circuit Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 04 Feb 2002 06:50:51.0000 (UTC) FILETIME=[48941780:01C1AD48] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g146mQL41729 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 4 Feb 2002 06:52:02 -0000 Content-Transfer-Encoding: 8bit Thanks Jeff for your input. I have another query regarding the Sec. 8.3.3 "RPF on DA Circuits".RPF Cache looks more or like Forwarding Cache at the Control plane. My doubt is, why the forwarding information is stored in ISIS. Assume there are Forwarding Cache, Routing table in Data plane and ISIS in control plane.How a packet is forwarded , if RPF information is stored in control plane?. Or the spec discusses generally why RPF is needed in DA circuits... "So where sits RPF Cache ?" is MY ULTIMATE QUESTION Thanks, V Nath On Fri, 01 Feb 2002 Jeff Learman wrote : > > Another way of looking at this is, when you do manually > configure a route, > you don't want to have to manually configure that route > on every router, > do you? Of course not. You only configure it at the > point of origin, > and IS-IS disseminates it throughout the rest of the > area/domain. > > Unfortunately, you can't use it to flood this > information across a > DA circuit. I think the idea was that in any sizeable > network, there > would be enough chatter on any link where IS-IS was run > that it > wouldn't make any sense for it to be a DA circuit. > Also, when the > link connects significant portions of a network, it > would normally > have enough traffic to justify a statically assigned > circuit. So, > while I said "unfortunate", I haven't seen any cases > where another > method didn't work better (e.g., static routing, BGP). > > Regards, > Jeff > > At 03:07 AM 2/1/2002, mike shand wrote: > >At 04:47 01/02/2002 +0000, Vijay Nath wrote: > > > >>mike, > >> > >> when only manual route is the solution, what is > need of router sending those manual route to other > routers.Even other routers too, have manual information > in their Reachable address prefix table, so it knows > where to send the pkt. > > > >No they don't. They may have reachable address > prefixes for OTHER prefixes, but not (necessarily) for > THIS prefix. Manual routing is NOT used (except under > VERY strange circumstances, and then usu only as a > result of misconfiguration) within the core of the > network. It is used to hang reachable addresses as > leaves off the the core tree. Often an RA will only > appear hung off one router, although sometimes they > will be "multi-homed". But the point is that you need > the propagation of the routing information about them > to make it all work. > > > >It may help you to think of reachable address prefixes > in exactly the same way as IP subnets. In a sense they > are "manual" routes since they are defined on the local > interface. But you still need to propagate this > information across the network so that other routers > can route to them. > > > >Reachable addresses on DA circuits are similar > > > > > >>In sec 8.3.5 > >> > >>"There causes this information to be included in > subsequently generated LSPs as described in > 7.3.3.2.Routeing PDUs (LSPs and SN PDUs) shall not be > sent on DA circuits" > >> > >>Two contradictory statements in a clause.Pl. explain > on this. > > > >Not contradictory at all! The information is included > in LSPs which are flooded, but NOT flooded over the DA > circuits themselves. > > > > Mike > > > > > > > >>TIA, > >>V Nath > >> > >> > >> > >> > >>On Fri, 01 Feb 2002 mike shand wrote : > >>> At 10:18 29/01/2002 +0000, Vijay Nath wrote: > >>> > >>> > >>> >Hi All, > >>> > > >>> > As per spec 10589, DA circuits shall not send > >>> Hellos, LSPs and > >>> > SNPs.Then how dynamic routing is achieved ??. > >>> >or it is not possible (dynamic routing) in DA > >>> circuits??. > >>> > >>> It's not possible. A DA circuit has a reachable > address > >>> prefix (aka manual > >>> route) attached to it, and the circuit is only > brought > >>> up when there is > >>> traffic to that destination. The manual route is of > >>> course advertised in > >>> LSPs and propagated to other routers so that they > know > >>> where to send the > >>> traffic. It was primarily designed for use with X.25 > >>> SVCs(which tells you > >>> how old it is), where you only want to > >>> > >>> Mike > >>> > >>> > >>> > >>> >TIA, > >>> >V Nath > >>> > > >>> >_______________________________________________ > >>> >Isis-wg mailing list - > Isis-wg@external.juniper.net > >>> >http://external.juniper.net/mailman/listinfo/isis-w- > g > >>> > >>> _______________________________________________ > >>> Isis-wg mailing list - > Isis-wg@external.juniper.net > >>> http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 4 13:58:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02974 for ; Mon, 4 Feb 2002 13:58:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g14Io1L45054; Mon, 4 Feb 2002 10:50:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g14ImmL45032 for ; Mon, 4 Feb 2002 10:49:18 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Laura Liu'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] RE: Questions about isis mib MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 4 Feb 2002 13:53:44 -0500 > ... will display the IP reachable route > grouped by its next hop interface. ....I would prefer > we add an entry like isisIPRANextHop (interface name > or IP net address as value) and remove isisCircIndex > in oid index. > > > Laura Laura - I read this as a suggestion that we index the table by IP address, as that makes more sense when walking the table. I think this is a reasonable request: any objections from the list? There was another request to change the index of the area address table to -NOT- use the address, but that was really due to the variable length format of OSI address, which made the access routines difficult to write. I think I could honor both requests with damage. - jeff parker > > isisIPRATable OBJECT-TYPE > > SYNTAX SEQUENCE OF IsisIPRAEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The table of IP Reachable Addresses to networks, > > subnetworks or hosts either manually configured or > > learned from another protocol." > > ::= { isisIPReachAddr 1 } > > > > isisIPRAEntry OBJECT-TYPE > > SYNTAX IsisIPRAEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Each entry defines an IP Reachable Address to > a network, > > subnetwork or host." > > INDEX { isisSysInstance, > > isisCircIndex, > > isisIPRAType, > > isisIPRAIndex } > > ::= { isisIPRATable 1 } > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 4 15:59:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05859 for ; Mon, 4 Feb 2002 15:59:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g14KqhL45629; Mon, 4 Feb 2002 12:52:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rchss002.chiaro.com (rchss002.chiaro.com [63.88.196.82]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g14KlcL45600 for ; Mon, 4 Feb 2002 12:47:38 -0800 (PST) (envelope-from lliu@chiaro.com) Received: (qmail 24501 invoked from network); 4 Feb 2002 20:49:33 -0000 Received: from rchss002.chiaro.com (HELO mail.chiaro.com) (63.88.196.82) by rchss002.chiaro.com with SMTP; 4 Feb 2002 20:49:33 -0000 Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 14:52:07 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A50701C4C3D6@MAIL> From: Laura Liu To: Jeff Parker , Laura Liu Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] RE: Questions about isis mib MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/mixed; boundary="=_IS_MIME_Boundary" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 4 Feb 2002 14:51:59 -0600 --=_IS_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Jeff, Thanks for taking my suggestion. I agree that with area address as index makes the access routine more difficult. But I could not think of a better or clear way for "get" command to access a specific area address. Just my two cents. best regards, Laura -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Monday, February 04, 2002 12:54 PM To: 'Laura Liu' Cc: IS-IS-WG (E-mail) Subject: RE: [Isis-wg] RE: Questions about isis mib > ... will display the IP reachable route > grouped by its next hop interface. ....I would prefer > we add an entry like isisIPRANextHop (interface name > or IP net address as value) and remove isisCircIndex > in oid index. > > > Laura Laura - I read this as a suggestion that we index the table by IP address, as that makes more sense when walking the table. I think this is a reasonable request: any objections from the list? There was another request to change the index of the area address table to -NOT- use the address, but that was really due to the variable length format of OSI address, which made the access routines difficult to write. I think I could honor both requests with damage. - jeff parker > > isisIPRATable OBJECT-TYPE > > SYNTAX SEQUENCE OF IsisIPRAEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The table of IP Reachable Addresses to networks, > > subnetworks or hosts either manually configured or > > learned from another protocol." > > ::= { isisIPReachAddr 1 } > > > > isisIPRAEntry OBJECT-TYPE > > SYNTAX IsisIPRAEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "Each entry defines an IP Reachable Address to > a network, > > subnetwork or host." > > INDEX { isisSysInstance, > > isisCircIndex, > > isisIPRAType, > > isisIPRAIndex } > > ::= { isisIPRATable 1 } > > > --=_IS_MIME_Boundary Content-Type: text/plain;charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit ----------------------------------------- (on Chiaro SMTP Relay) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- --=_IS_MIME_Boundary-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 5 09:56:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02204 for ; Tue, 5 Feb 2002 09:56:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g15El1L50500; Tue, 5 Feb 2002 06:47:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g15EkOL50488 for ; Tue, 5 Feb 2002 06:46:25 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g15EpYc03445 for ; Tue, 5 Feb 2002 06:51:34 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Feb 2002 06:50:05 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01669; Tue, 5 Feb 2002 09:50:44 -0500 (EST) Message-Id: <200202051450.JAA01669@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 05 Feb 2002 14:50:06.0062 (UTC) FILETIME=[665818E0:01C1AE54] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-08.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 05 Feb 2002 09:50:43 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-08.txt Pages : 10 Date : 04-Feb-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-08.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: <20020204134031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020204134031.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 19:47:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14364 for ; Thu, 7 Feb 2002 19:47:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g180d1L64642; Thu, 7 Feb 2002 16:39:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g180cfL64630 for ; Thu, 7 Feb 2002 16:38:42 -0800 (PST) (envelope-from Amit.Goyal@nokia.com) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.americas.nokia.com [172.18.194.217]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g180hg329258 for ; Fri, 8 Feb 2002 02:43:42 +0200 (EET) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g180jrQ04026 for ; Thu, 7 Feb 2002 18:45:53 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 7 Feb 2002 18:44:03 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Feb 2002 18:43:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Questions Thread-Index: AcGwOaAA9lsIcNnGQ1u1I2g3Jtluyg== From: To: X-OriginalArrivalTime: 08 Feb 2002 00:43:29.0348 (UTC) FILETIME=[A061E840:01C1B039] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g180cgL64631 Subject: [Isis-wg] Questions Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 7 Feb 2002 16:43:28 -0800 Content-Transfer-Encoding: 8bit Hi, Currently I am working on ISIS and have two questions 1. In some old mail somebody described that a lot of ISPs were using ISIS at that time (I guess it was in 99). Is it still true? Also do we know whether the use of ISIS among ISPs has increased or decreased since then? 2. I am looking for "A comparison between two routing protocols" "OSPF and IS-IS" by R. Perlman. Where can I get it from? I don't want to start any controversies by asking for comparison. This is purely for getting more information about both protocols. Regards Amit _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 20:13:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14838 for ; Thu, 7 Feb 2002 20:13:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g18161L64843; Thu, 7 Feb 2002 17:06:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sundmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1815EL64831 for ; Thu, 7 Feb 2002 17:05:14 -0800 (PST) (envelope-from tli@Procket.com) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz1.procket.com (Postfix) with ESMTP id 926CF23C27; Thu, 7 Feb 2002 17:02:04 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g181Adr6011738; Thu, 7 Feb 2002 17:10:39 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g181AcdJ024430; Thu, 7 Feb 2002 17:10:38 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15459.9614.861714.22165@alpha-tli.procket.com> To: Cc: Subject: [Isis-wg] Questions In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 7 Feb 2002 17:10:38 -0800 Content-Transfer-Encoding: 7bit | 1. In some old mail somebody described that a lot of ISPs were using | ISIS at that time (I guess it was in 99). Is it still true? Also do | we know whether the use of ISIS among ISPs has increased or decreased | since then? I am unaware of any serious studies. My (admittedly biased ;-) gut says that there are many ISPs using IS-IS, and that the percentage is on the rise, mostly thanks to the demise of ISPs not using IS-IS. I also believe that there is a large correlation between use of IS-IS and size of ISP. | 2. I am looking for "A comparison between two routing protocols" "OSPF | and IS-IS" by R. Perlman. Where can I get it from? | | I don't want to start any controversies by asking for comparison. This | is purely for getting more information about both protocols. That's probably the most controversial question that you could have asked. ;-) In order to stem the tide, let me put on my WG co-chair hat on and ask that people NOT start this discussion, please. In the dusty corners of my memory, I recall that someone did do a scholarly paper on the subject. If someone has a pointer to that, could you please post it? Thanks. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 20:25:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15018 for ; Thu, 7 Feb 2002 20:25:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181I0L64917; Thu, 7 Feb 2002 17:18:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181HUL64905 for ; Thu, 7 Feb 2002 17:17:30 -0800 (PST) (envelope-from jharper@cisco.com) Received: from JHARPER-W2K1.cisco.com (dhcp-128-107-163-84.cisco.com [128.107.163.84]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id BAA17492; Fri, 8 Feb 2002 01:22:50 GMT Message-Id: <4.3.2.7.2.20020207172036.02128378@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Li From: John Harper Subject: Re: [Isis-wg] Questions Cc: , In-Reply-To: <15459.9614.861714.22165@alpha-tli.procket.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 07 Feb 2002 17:22:53 -0800 At 17:10 07/02/2002 -0800, Tony Li wrote: >| 2. I am looking for "A comparison between two routing protocols" "OSPF > | and IS-IS" by R. Perlman. Where can I get it from? > | > | I don't want to start any controversies by asking for comparison. This > | is purely for getting more information about both protocols. > >In the dusty corners of my memory, I recall that someone did do a scholarly >paper on the subject. If someone has a pointer to that, could you please >post it? Thanks. Alex Zinin did a preso a couple of years ago. Although Alex is a self-confessed OSPF person, the preso was pretty well balanced and the bottom line was that, rather like which way the water spins around the plughole, the dominant factor is what you are doing already. (I think it was Alex anyway). (I happen to share Tony's views on this but my job rather obliges me to be pragmatic). John _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 20:36:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15241 for ; Thu, 7 Feb 2002 20:35:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181T1L64992; Thu, 7 Feb 2002 17:29:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from tcb.net (tcb.net [205.168.100.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181S7L64980 for ; Thu, 7 Feb 2002 17:28:07 -0800 (PST) (envelope-from danny@dog.tcb.net) Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g181NhN17293 for ; Thu, 7 Feb 2002 18:23:44 -0700 Message-Id: <200202080123.g181NhN17293@tcb.net> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: isis-wg@spider.juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] Questions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 07 Feb 2002 18:23:43 -0700 > Currently I am working on ISIS and have two questions > 1. In some old mail somebody described that a lot of ISPs > were using ISIS at that time (I guess it was in 99). Is it > still true? I actually did a survey a while back and found that of the largest 10 domestic ISPs ~7 used IS-IS, the remaining 3 used OSPF. Of the ~70 networks I had knowledge of (either as a result of direct involvement, directed queries or publicly solicited responses) ~15 used IS-IS while the rest used OSPF (minus a few stragglers using EIGRP or the like). [Disclaimer: "Largest 10" is purely in my mind, I did no customer counts, IP counts or the like in an attempt to qualify my employment of the phrase.] It's quite reasonable to assume that the number of IS-IS ISP networks decreases substantially thereafter. And I'm guessing there are very very few enterprises that employ IS-IS as their IP IGP -- for obvious reasons. > Also do we know whether the use of ISIS among > ISPs has increased or decreased since then? It really hasn't changed a whole lot since '99, other than the demise of lots of the "Broadband CLECs" and the like., of which a much greater amount of OSPF seemed to be deployed. > 2. I am looking for "A comparison between two routing protocols" > "OSPF and IS-IS" by R. Perlman. Where can I get it from? I'm guessing you're talking about the great IGP Debate from "CONNEXIONS: The Interoperability Report", October 1991 Vol 5, No. 10 (I had a copy on my bookshelf, if you're wondering :-). Radia & Ross Callon discussed IS-IS and Mile Medin discussed OSPF. Of course, it's really dated and not of a great deal of use today, IMO. A more useful reference is perhaps this: http://www.nanog.org/mtg-0006/katz.html Reasons for all of the above have been hashed out here and on other mailing lists for quite a while, so I'll not discuss anything further here... HTH, -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 20:36:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15259 for ; Thu, 7 Feb 2002 20:36:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181U1L65024; Thu, 7 Feb 2002 17:30:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from [172.16.1.15] (smtp1.opnet.com [141.156.71.6]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181TqL65009 for ; Thu, 7 Feb 2002 17:29:52 -0800 (PST) (envelope-from azalani@opnet.com) Received: from wtn10068 (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 7 Feb 2002 20:35:13 -0500 Message-Id: <4.2.1.20020207203252.00b22890@mail.opnet.com> X-Sender: azalani@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 To: , From: Ashish Zalani Subject: Re: [Isis-wg] Questions In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 07 Feb 2002 20:35:12 -0500 At 04:43 PM 2/7/02 -0800, Amit.Goyal@nokia.com wrote: >2. I am looking for "A comparison between two routing protocols" "OSPF and >IS-IS" by R. Perlman. Where can I get it from? This may not be exactly what you are looking for, but Radia Perlman has authored a book titled "Interconnections" in which she does a fair comparison of IS-IS and OSPF (along with PNNI and NLSP) as Link State Routing Protocols. -Ashish. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 20:38:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15276 for ; Thu, 7 Feb 2002 20:38:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181V0L65048; Thu, 7 Feb 2002 17:31:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from vivacenetworks.com ([64.221.212.130]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181UCL65036 for ; Thu, 7 Feb 2002 17:30:12 -0800 (PST) (envelope-from Ravindra.Sunkad@VivaceNetworks.com) X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Questions Message-ID: Thread-Topic: [Isis-wg] Questions Thread-Index: AcGwOaAA9lsIcNnGQ1u1I2g3JtluygAB1wBg From: "Ravindra Sunkad" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g181UCL65037 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 7 Feb 2002 17:35:34 -0800 Content-Transfer-Encoding: 8bit Amit, Here's one pointer: http://www.nanog.org/mtg-0006/katz.html Ravi > -----Original Message----- > From: Amit.Goyal@nokia.com [mailto:Amit.Goyal@nokia.com] > Sent: Thursday, February 07, 2002 4:43 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] Questions > > Hi, > Currently I am working on ISIS and have two questions > 1. In some old mail somebody described that a lot of ISPs were using ISIS > at that time (I guess it was in 99). Is it still true? Also do we know > whether the use of ISIS among ISPs has increased or decreased since then? > 2. I am looking for "A comparison between two routing protocols" "OSPF and > IS-IS" by R. Perlman. Where can I get it from? > > I don't want to start any controversies by asking for comparison. This is > purely for getting more information about both protocols. > Regards > Amit > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 20:48:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15393 for ; Thu, 7 Feb 2002 20:48:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181f1L65151; Thu, 7 Feb 2002 17:41:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181eCL65134 for ; Thu, 7 Feb 2002 17:40:13 -0800 (PST) (envelope-from jharper@cisco.com) Received: from JHARPER-W2K1.cisco.com (dhcp-128-107-163-84.cisco.com [128.107.163.84]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id BAA18062; Fri, 8 Feb 2002 01:45:32 GMT Message-Id: <4.3.2.7.2.20020207174517.041a5e88@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ravindra Sunkad" From: John Harper Subject: RE: [Isis-wg] Questions Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 07 Feb 2002 17:45:34 -0800 That's the one I was thinking of. (Guess it wasn't Alex after all). John At 17:35 07/02/2002 -0800, Ravindra Sunkad wrote: >Amit, > >Here's one pointer: >http://www.nanog.org/mtg-0006/katz.html > >Ravi > > > -----Original Message----- > > From: Amit.Goyal@nokia.com [mailto:Amit.Goyal@nokia.com] > > Sent: Thursday, February 07, 2002 4:43 PM > > To: isis-wg@spider.juniper.net > > Subject: [Isis-wg] Questions > > > > Hi, > > Currently I am working on ISIS and have two questions > > 1. In some old mail somebody described that a lot of ISPs were using >ISIS > > at that time (I guess it was in 99). Is it still true? Also do we know > > whether the use of ISIS among ISPs has increased or decreased since >then? > > 2. I am looking for "A comparison between two routing protocols" "OSPF >and > > IS-IS" by R. Perlman. Where can I get it from? > > > > I don't want to start any controversies by asking for comparison. This >is > > purely for getting more information about both protocols. > > Regards > > Amit > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 20:57:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15572 for ; Thu, 7 Feb 2002 20:57:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181p0L65239; Thu, 7 Feb 2002 17:51:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g181owL65227 for ; Thu, 7 Feb 2002 17:50:58 -0800 (PST) (envelope-from Amit.Goyal@nokia.com) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g181uSZ05482 for ; Fri, 8 Feb 2002 03:56:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 8 Feb 2002 03:56:23 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Feb 2002 03:56:22 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Feb 2002 19:56:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: [Isis-wg] Questions Thread-Index: AcGwQOKpO8AzXajnT/2eawELkKT/ywAAmnIA From: To: X-OriginalArrivalTime: 08 Feb 2002 01:56:19.0721 (UTC) FILETIME=[CD53E790:01C1B043] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g181oxL65228 Subject: [Isis-wg] Forwarding database for IP only Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 7 Feb 2002 17:56:18 -0800 Content-Transfer-Encoding: 8bit Hi, Thanks all for your replies. I have one more question. RFC 1195 annex C explains the forwarding algorithm for both OSI and IP. I was wondering if it is possible to remove OSI computation from IP only router. Do we have any paper for the optimization for IP only routers in ISIS? Regards Amit _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 7 22:45:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19093 for ; Thu, 7 Feb 2002 22:45:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g183c0L65702; Thu, 7 Feb 2002 19:38:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g183b8L65690 for ; Thu, 7 Feb 2002 19:37:08 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g183gW645230; Thu, 7 Feb 2002 19:42:32 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g183gV506826; Thu, 7 Feb 2002 19:42:31 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200202080342.g183gV506826@cirrus.juniper.net> From: Dave Katz To: jharper@cisco.com CC: tli@procket.com, Amit.Goyal@nokia.com, isis-wg@spider.juniper.net In-reply-to: <4.3.2.7.2.20020207172036.02128378@jaws.cisco.com> (message from John Harper on Thu, 07 Feb 2002 17:22:53 -0800) Subject: Re: [Isis-wg] Questions References: <4.3.2.7.2.20020207172036.02128378@jaws.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 7 Feb 2002 19:42:31 -0800 (PST) I did one at NANOG in June of 2000; the slides are in the NANOG archives I think. X-Sender: jharper@jaws.cisco.com From: John Harper Cc: , Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 07 Feb 2002 17:22:53 -0800 At 17:10 07/02/2002 -0800, Tony Li wrote: >| 2. I am looking for "A comparison between two routing protocols" "OSPF > | and IS-IS" by R. Perlman. Where can I get it from? > | > | I don't want to start any controversies by asking for comparison. This > | is purely for getting more information about both protocols. > >In the dusty corners of my memory, I recall that someone did do a scholarly >paper on the subject. If someone has a pointer to that, could you please >post it? Thanks. Alex Zinin did a preso a couple of years ago. Although Alex is a self-confessed OSPF person, the preso was pretty well balanced and the bottom line was that, rather like which way the water spins around the plughole, the dominant factor is what you are doing already. (I think it was Alex anyway). (I happen to share Tony's views on this but my job rather obliges me to be pragmatic). John _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 8 01:16:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21230 for ; Fri, 8 Feb 2002 01:16:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g18670L66329; Thu, 7 Feb 2002 22:07:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mozzer.routingloop.com (mozzer.routingloop.com [216.170.22.222]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1866FL66317 for ; Thu, 7 Feb 2002 22:06:15 -0800 (PST) (envelope-from alan@mozzer.routingloop.com) Received: from mozzer.routingloop.com (localhost [127.0.0.1]) by mozzer.routingloop.com (8.12.1/42.69.7) with ESMTP id g186BQPr045512; Thu, 7 Feb 2002 22:11:26 -0800 (PST) (envelope-from alan@mozzer.routingloop.com) Received: (from alan@localhost) by mozzer.routingloop.com (8.12.1/8.12.1/Submit) id g186BQI8045511; Thu, 7 Feb 2002 22:11:26 -0800 (PST) (envelope-from alan) From: Alan Hannan To: Amit.Goyal@nokia.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Questions Message-ID: <20020207221125.A24698@routingloop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Amit.Goyal@nokia.com on Thu, Feb 07, 2002 at 04:43:28PM -0800 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 7 Feb 2002 22:11:26 -0800 > 2. I am looking for "A comparison between two routing protocols" "OSPF and IS-IS" by R. Perlman. Where can I get it from? http://citeseer.nj.nec.com/context/50541/0 R. Perlman. A comparison between two routing protocols: OSPF and IS-IS. IEEE Networks.vol.5,Sept. 1991, pp. 18-24. I suspect you could get this from IEEE archives, but I haven't checked. I think they're scanning stuff in from that far back.... (from google http://www.google.com/search?sourceid=navclient&q=A+comparison+between+two+routing+protocols+Radia+Perlman) -a _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 8 01:30:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21372 for ; Fri, 8 Feb 2002 01:30:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g186N1L66417; Thu, 7 Feb 2002 22:23:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.nexsi.com (ripper2.nexsi.com [66.35.212.41]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g186MrL66405 for ; Thu, 7 Feb 2002 22:22:53 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from khonsu.sw.nexsi.com (cscovpn0.nexsi.com [172.16.213.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id WAA17935; Thu, 7 Feb 2002 22:27:24 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1982346373.20020207222724@nexsi.com> To: John Harper CC: "Ravindra Sunkad" , Amit.Goyal@nokia.com, Subject: Re: [Isis-wg] Questions In-Reply-To: <4.3.2.7.2.20020207174517.041a5e88@jaws.cisco.com> References: <4.3.2.7.2.20020207174517.041a5e88@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 7 Feb 2002 22:27:24 -0800 Content-Transfer-Encoding: 7bit John, Yeah, thanks for credit, but that's all Dave's fault :) You're still right though. Peter Psenak, (as well as possibly Stefano or Mike, not sure) and I also did one, but I think it stayed Cisco internal or something. Radia, myself and other folks also talked about a [unbiased] comparison white paper, but that never took off. -- Alex Zinin Thursday, February 07, 2002, 5:45:34 PM, John Harper wrote: > That's the one I was thinking of. (Guess it wasn't Alex after all). > John > At 17:35 07/02/2002 -0800, Ravindra Sunkad wrote: >>Amit, >> >>Here's one pointer: >>http://www.nanog.org/mtg-0006/katz.html >> >>Ravi >> >> > -----Original Message----- >> > From: Amit.Goyal@nokia.com [mailto:Amit.Goyal@nokia.com] >> > Sent: Thursday, February 07, 2002 4:43 PM >> > To: isis-wg@spider.juniper.net >> > Subject: [Isis-wg] Questions >> > >> > Hi, >> > Currently I am working on ISIS and have two questions >> > 1. In some old mail somebody described that a lot of ISPs were using >>ISIS >> > at that time (I guess it was in 99). Is it still true? Also do we know >> > whether the use of ISIS among ISPs has increased or decreased since >>then? >> > 2. I am looking for "A comparison between two routing protocols" "OSPF >>and >> > IS-IS" by R. Perlman. Where can I get it from? >> > >> > I don't want to start any controversies by asking for comparison. This >>is >> > purely for getting more information about both protocols. >> > Regards >> > Amit >> > _______________________________________________ >> > Isis-wg mailing list - Isis-wg@external.juniper.net >> > http://external.juniper.net/mailman/listinfo/isis-wg >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@external.juniper.net >>http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 8 02:02:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24403 for ; Fri, 8 Feb 2002 02:02:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g186t1L66571; Thu, 7 Feb 2002 22:55:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g186sYL66556 for ; Thu, 7 Feb 2002 22:54:35 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A2E524BA219; Thu, 7 Feb 2002 23:00:01 -0800 (PST) To: Amit.Goyal@nokia.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Questions In-reply-to: Mail from Tony Li dated Thu, 07 Feb 2002 17:10:38 PST <15459.9614.861714.22165@alpha-tli.procket.com> From: Naiming Shen Message-Id: <20020208070001.A2E524BA219@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 07 Feb 2002 23:00:01 -0800 checkout this nanog thread, but it seems author giving lots of credit to ospf: http://www.merit.edu/mail.archives/nanog/1999-01/msg00012.html cheers. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 8 09:40:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08205 for ; Fri, 8 Feb 2002 09:40:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g18EX0L68894; Fri, 8 Feb 2002 06:33:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g18EWvL68882 for ; Fri, 8 Feb 2002 06:32:57 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g18Ecel22164; Fri, 8 Feb 2002 09:38:40 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAS39353; Fri, 8 Feb 2002 09:38:22 -0500 (EST) Message-Id: <4.3.2.7.2.20020208093035.03ae4008@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: Re: [Isis-wg] Forwarding database for IP only Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 08 Feb 2002 09:38:07 -0500 Amit, At 08:56 PM 2/7/2002, Amit.Goyal@nokia.com wrote: >RFC 1195 annex C explains the forwarding algorithm for both OSI and IP. I was wondering if it is possible to remove OSI computation from IP only router. Do we have any paper for the optimization for IP only routers in ISIS? >Regards While I haven't studied this with the diligence required for a scholarly paper, I have given it a bit of thought. My opinion is that, in a network that is constructed according to RFC-1195's deployment rules, there would be no observable behavior difference between a router that runs a protocol- specific SPF per supported protocol and one that runs SPF including all protocols. The reason is simply that the deployment rules require all the ISs in the subdomain (L1 area or L2 backbone) to support the same set of protocols. Regards, Jeff Disclaimer: I have not worked on IS-IS at Cisco. My opinions are my own and do not necessarily reflect those of my employer. >Amit > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Feb 9 18:08:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20456 for ; Sat, 9 Feb 2002 18:08:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g19N00L79159; Sat, 9 Feb 2002 15:00:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g19MxWL79141 for ; Sat, 9 Feb 2002 14:59:32 -0800 (PST) (envelope-from Ming.Chan@SpirentCom.COM) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.10.2+Sun/8.10.2) with ESMTP id g19N58f05909 for ; Sat, 9 Feb 2002 13:05:08 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1KRJ18HF>; Sat, 9 Feb 2002 13:11:09 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540502DD6761@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: isis-wg@spider.juniper.net Cc: "Chan, Chung Ming" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Isis-wg] Question on the usage of ISH and P2PIIH Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 9 Feb 2002 13:11:07 -1000 Hi, I would like to find out that "On the p2p circuit, should an IS go to Up State if a valid P2P IIH is received before receiving any ISH?" Apparently, one vendor's router in our lab, ignore/does not rely on ISH for their p2p operation. Would that be any implication of not using ISH for bringing p2p link adj to up state? Thanks, Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 10 21:04:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13500 for ; Sun, 10 Feb 2002 21:04:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1B1thL86845; Sun, 10 Feb 2002 17:55:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.227.69]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1B1pvL86816 for ; Sun, 10 Feb 2002 17:51:57 -0800 (PST) (envelope-from svemulap@cisco.com) Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.102.160]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA02021; Sun, 10 Feb 2002 17:57:41 -0800 (PST) From: Shankar Vemulapalli To: "Chan, Chung Ming" cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH In-Reply-To: <8AC36D3167EED41184C800508BD9540502DD6761@apollo.adtech-inc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 10 Feb 2002 17:57:19 -0800 (PST) *I believe* ISO10589 mentions that we need to send both IIH and ISH packets eventhough IIH packets are used to form the IS-IS adjacencies. I am not sure on the implementation details of any vendor. At a high level I would assume that there wont' be any implication if an IS doesn't send any ISH as there is no any ES on a p2p interface... But for sure ISO 10589 may have a reason for IS to send ISH packets. Thanks, /Shankar At 1:11pm 02/09/02 -1000, Chan, Chung Ming wrote: > Hi, > > I would like to find out that "On the p2p circuit, should an IS go > to Up State if a valid P2P IIH is received before receiving any ISH?" > Apparently, one vendor's router in our lab, ignore/does not rely on > ISH for their p2p operation. > Would that be any implication of not using ISH for bringing p2p link > adj to up state? > > > Thanks, > > > > Ming Chan > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 10 23:51:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17260 for ; Sun, 10 Feb 2002 23:51:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1B4hPL87635; Sun, 10 Feb 2002 20:43:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1B4XlL87584 for ; Sun, 10 Feb 2002 20:33:47 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1B4dlk19279; Sun, 10 Feb 2002 23:39:47 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn1-439.cisco.com [10.82.225.183]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAS70281; Sun, 10 Feb 2002 23:39:29 -0500 (EST) Message-Id: <4.3.2.7.2.20020210233015.038f2ee8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Shankar Vemulapalli From: Jeff Learman Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: "Chan, Chung Ming" , isis-wg@spider.juniper.net In-Reply-To: References: <8AC36D3167EED41184C800508BD9540502DD6761@apollo.adtech-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 10 Feb 2002 23:37:07 -0500 At 08:57 PM 2/10/2002, Shankar Vemulapalli wrote: >*I believe* ISO10589 mentions that we need to send both IIH and ISH packets >eventhough IIH packets are used to form the IS-IS adjacencies. I am not sure >on the implementation details of any vendor. > >At a high level I would assume that there wont' be any implication if an IS >doesn't send any ISH as there is no any ES on a p2p interface... But for sure >ISO 10589 may have a reason for IS to send ISH packets. The reason ISO 10589 requires a router to send ISH packets is that it was written for OSI networking (CLNP/ESIS), and the ISH packet is how the end systems discover the router. This reason does not apply to IS-IS when used for IP only. Furthermore, receipt of an ISH should not be required to bring an IS-IS adjacency to the initializing or up states. I don't have 10589 handy, but I don't think it requires receipt of an ISH. If it does, I bet it was corrected in a TC. Regards, Jeff Disclaimer: I have not worked on IS-IS at Cisco, and my opinions may not reflect those of my employer. >Thanks, > >/Shankar > >At 1:11pm 02/09/02 -1000, Chan, Chung Ming wrote: >> Hi, >> >> I would like to find out that "On the p2p circuit, should an IS go >> to Up State if a valid P2P IIH is received before receiving any ISH?" >> Apparently, one vendor's router in our lab, ignore/does not rely on >> ISH for their p2p operation. >> Would that be any implication of not using ISH for bringing p2p link >> adj to up state? >> >> >> Thanks, >> >> >> >> Ming Chan >> >> >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg >> > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 11 00:20:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17512 for ; Mon, 11 Feb 2002 00:20:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1B5D8L87801; Sun, 10 Feb 2002 21:13:08 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1B4xdL87729 for ; Sun, 10 Feb 2002 20:59:39 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <1NRH3PNH>; Mon, 11 Feb 2002 00:05:19 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'Jeff Learman'" Cc: "Chan, Chung Ming" , isis-wg@spider.juniper.net, Shankar Vemulapalli Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Feb 2002 00:05:10 -0500 ISO 10589:2001 says still that on receipt of ISH PDU, a IS can create adjacency with adj State "Init" and nbr Sys Type "unknown" > -----Original Message----- > From: Jeff Learman [mailto:jlearman@cisco.com] > Sent: Monday, February 11, 2002 10:07 AM > To: Shankar Vemulapalli > Cc: Chan, Chung Ming; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH > > > At 08:57 PM 2/10/2002, Shankar Vemulapalli wrote: > >*I believe* ISO10589 mentions that we need to send both IIH > and ISH packets > >eventhough IIH packets are used to form the IS-IS > adjacencies. I am not sure > >on the implementation details of any vendor. > > > >At a high level I would assume that there wont' be any > implication if an IS > >doesn't send any ISH as there is no any ES on a p2p > interface... But for sure > >ISO 10589 may have a reason for IS to send ISH packets. > > The reason ISO 10589 requires a router to send ISH packets is that it > was written for OSI networking (CLNP/ESIS), and the ISH packet is how > the end systems discover the router. This reason does not apply to > IS-IS when used for IP only. > > Furthermore, receipt of an ISH should not be required to bring an > IS-IS adjacency to the initializing or up states. I don't have 10589 > handy, but I don't think it requires receipt of an ISH. If it does, > I bet it was corrected in a TC. > > Regards, > Jeff > > Disclaimer: I have not worked on IS-IS at Cisco, and my opinions may > not reflect those of my employer. > > > >Thanks, > > > >/Shankar > > > >At 1:11pm 02/09/02 -1000, Chan, Chung Ming wrote: > >> Hi, > >> > >> I would like to find out that "On the p2p circuit, > should an IS go > >> to Up State if a valid P2P IIH is received before > receiving any ISH?" > >> Apparently, one vendor's router in our lab, > ignore/does not rely on > >> ISH for their p2p operation. > >> Would that be any implication of not using ISH for > bringing p2p link > >> adj to up state? > >> > >> > >> Thanks, > >> > >> > >> > >> Ming Chan > >> > >> > >> > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > >> > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 11 09:51:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04242 for ; Mon, 11 Feb 2002 09:51:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BEi7L90864; Mon, 11 Feb 2002 06:44:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BEYML90813 for ; Mon, 11 Feb 2002 06:34:22 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 24402 invoked from network); 11 Feb 2002 14:40:10 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 11 Feb 2002 14:40:10 -0000 From: "Ken Larmer" To: "Jeff Learman" , "Shankar Vemulapalli" Cc: "Chan, Chung Ming" , Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20020210233015.038f2ee8@dingdong.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Feb 2002 09:45:38 -0500 Content-Transfer-Encoding: 7bit > The reason ISO 10589 requires a router to send ISH packets is that it > was written for OSI networking (CLNP/ESIS), and the ISH packet is how > the end systems discover the router. This reason does not apply to > IS-IS when used for IP only. > > Furthermore, receipt of an ISH should not be required to bring an > IS-IS adjacency to the initializing or up states. I don't have 10589 > handy, but I don't think it requires receipt of an ISH. If it does, > I bet it was corrected in a TC. I believe that we must be very careful when providing advice from this working group about implementing Int IS-IS in ways which do not abide by ISO-10589 and/or RFC-1195. An ISH is used by ISO-10589 for many purposes other than letting an ES know that it is connected to an IS. An ISH is an integral part of the PtP initialization process and it also tells the IS initializing if it is connected to another IS or an ES. If an implementer does not properly take into account the affects of not receiving an ISH or transmitting an ISH, they could surely end up with scenarios where their implementation will not properly initialize with another vendor's product under all conceivable conditions. May I suggest that if there is a consensus that we do not need an ISH, we modify the specifications accordingly so that everyone implementing Int IS-IS in accordance with the appropriate specifications will possess a better chance of achieving full interoperability with other vendors implementing Int IS-IS in accordance with the same specifications. BTW, are we sure that we do not need to send ISH PDUs? What about those very few customer's who are using Integrated IS-IS as a routing protocol to forward both IP and CLNP packets. When I was at DEC in another lifetime, there were several customers (both core service providers and enterprise networks) which were using Int IS-IS for these purposes. Just my thoughts? Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 11 11:05:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07334 for ; Mon, 11 Feb 2002 11:05:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BFvoL91224; Mon, 11 Feb 2002 07:57:50 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BFeJL91138 for ; Mon, 11 Feb 2002 07:40:19 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1BFkLZ24181; Mon, 11 Feb 2002 10:46:21 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAS77461; Mon, 11 Feb 2002 10:46:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020211100227.038f6ae8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: "Shankar Vemulapalli" , "Chan, Chung Ming" , In-Reply-To: References: <4.3.2.7.2.20020210233015.038f2ee8@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Feb 2002 10:45:58 -0500 Note that I did not say that an IS need not send an ISH. I said that it should be able to bring up an adjacency without receiving one. 10589:1992, as amended by Cor. 1:1993, requires sending an ISH on a point-to-point circuit "when the circuit is first enabled" (an unfortunate choice of phrase; it should have said "when the link is established"). However, implementations that don't follow TC1 might not send an ISH, so it would be unwise to assume that every other router will send one. Furthermore, my interpretation of 10589 is that any router that fails to bring up the adjacency if it does not receive the ISH is not adhering to 10589 Section 8.2.2. As I remember it (hazily), the reason for this particular change in TC1 was to avoid sending IIH PDUs on point-to-point links to end systems. Sending an ISH first and waiting for an ISH before sending an IIH prevented that, provided that the end system sends an ESH. Note that, even with TC1, if an IS receives an IIH, this is sufficient to move the state machine forward towards bringing the adjacency up. Sending the initial ISH is a good idea from the general rule "Be strict in what you require of yourself and liberal in what you expect of others." Other than that general maxim, I don't know of any benefit it provides when used on a link where one side or the other doesn't support CLNP. Note that the initial ISH can't be used to indicate a link or router reset on an unreliable link, because it is legal to send the ISH periodically. According to a SONET Interoperability Forum (SIF) agreement, it's not necessary to send the ISH periodically. 10589 is ambiguous on this point. On an unreliable link, the 3-way handshake is needed to detect a router or link reset. Bottom line, by my interpretation: an IS is required to send an ISH, but it must not expect other routers to send one. Regards, Jeff Disclaimer: I don't speak for Cisco. At 09:45 AM 2/11/2002, Ken Larmer wrote: >> The reason ISO 10589 requires a router to send ISH packets is that it >> was written for OSI networking (CLNP/ESIS), and the ISH packet is how >> the end systems discover the router. This reason does not apply to >> IS-IS when used for IP only. >> >> Furthermore, receipt of an ISH should not be required to bring an >> IS-IS adjacency to the initializing or up states. I don't have 10589 >> handy, but I don't think it requires receipt of an ISH. If it does, >> I bet it was corrected in a TC. > > I believe that we must be very careful when providing advice from this >working group about implementing Int IS-IS in ways which do not abide by >ISO-10589 and/or RFC-1195. An ISH is used by ISO-10589 for many purposes >other than letting an ES know that it is connected to an IS. An ISH is an >integral part of the PtP initialization process and it also tells the IS >initializing if it is connected to another IS or an ES. > > If an implementer does not properly take into account the affects of not >receiving an ISH or transmitting an ISH, they could surely end up with >scenarios where their implementation will not properly initialize with >another vendor's product under all conceivable conditions. May I suggest >that if there is a consensus that we do not need an ISH, we modify the >specifications accordingly so that everyone implementing Int IS-IS in >accordance with the appropriate specifications will possess a better chance >of achieving full interoperability with other vendors implementing Int IS-IS >in accordance with the same specifications. > > BTW, are we sure that we do not need to send ISH PDUs? What about those >very few customer's who are using Integrated IS-IS as a routing protocol to >forward both IP and CLNP packets. When I was at DEC in another lifetime, >there were several customers (both core service providers and enterprise >networks) which were using Int IS-IS for these purposes. > > Just my thoughts? > >Cheers, >Ken Larmer >CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 11 13:24:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13276 for ; Mon, 11 Feb 2002 13:24:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BIGWL91890; Mon, 11 Feb 2002 10:16:32 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sundmz2.procket.com (dmz2.procket.com [65.174.124.37]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BHoZL91766 for ; Mon, 11 Feb 2002 09:50:35 -0800 (PST) (envelope-from tli@procket.com) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz2.procket.com (Postfix) with ESMTP id 8B14734429; Mon, 11 Feb 2002 09:59:08 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g1BHuNqu028415; Mon, 11 Feb 2002 09:56:23 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g1BHuNat006776; Mon, 11 Feb 2002 09:56:23 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15464.1479.346298.819926@alpha-tli.procket.com> To: Jeff Learman Cc: "Ken Larmer" , "Shankar Vemulapalli" , "Chan, Chung Ming" , Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH In-Reply-To: <4.3.2.7.2.20020211100227.038f6ae8@dingdong.cisco.com> References: <4.3.2.7.2.20020210233015.038f2ee8@dingdong.cisco.com> <4.3.2.7.2.20020211100227.038f6ae8@dingdong.cisco.com> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Feb 2002 09:56:23 -0800 Content-Transfer-Encoding: 7bit | Bottom line, by my interpretation: an IS is required to send an ISH, | but it must not expect other routers to send one. Minimalist viewpoint: the number of end systems out there is vanishingly small and growing smaller by the day. The thought of an end system at the end of a point-to-point link then decreases the numbers by another three orders of magnitude. This seems like work that could be avoided without dire consequences. IS's that wanted to support this certainly could, but the rest of us don't really gain by it... An RFC that said so would be a fine thing... Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 09:28:48 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12998 for ; Tue, 12 Feb 2002 09:28:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CEKPL97868; Tue, 12 Feb 2002 06:20:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from tahoe.allegronetworks.com ([63.115.58.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BIZtL91997 for ; Mon, 11 Feb 2002 10:35:55 -0800 (PST) (envelope-from cast@allegronetworks.com) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id <137B5MJ1>; Mon, 11 Feb 2002 10:40:44 -0800 Message-ID: From: Neal Castagnoli To: "'Jeff Learman'" , Shankar Vemulapalli Cc: "Chan, Chung Ming" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Feb 2002 10:40:43 -0800 > > Furthermore, receipt of an ISH should not be required to bring an > IS-IS adjacency to the initializing or up states. I don't have 10589 > handy, but I don't think it requires receipt of an ISH. If it does, > I bet it was corrected in a TC. Both 10589 and the second edition contain the text: c) The first Point-to-point IIH PDU (i.e. that transmitted as a result of receiving an ISH PDU, rather than as a result of timer expiration) . . . but the second removes first edition text which compelled initial IIH transmission at other times (for instance when the circuit first comes up). Therefore, strict second edition implementations require receipt of an ISH before transmitting an IIH. (I think someone pointed out they changed this in some ISO technical corrigendum or other.) Incidentally, I'm not advocating this behavior, just reporting what the spec sez. --Neal _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 09:29:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13047 for ; Tue, 12 Feb 2002 09:29:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CEMTL97939; Tue, 12 Feb 2002 06:22:29 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1C8YKL95799 for ; Tue, 12 Feb 2002 00:34:20 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp140.cisco.com [10.50.0.139]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA05770; Tue, 12 Feb 2002 08:40:00 GMT Message-Id: <4.3.2.7.2.20020212083731.00bafab0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Li From: mike shand Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: Jeff Learman , "Ken Larmer" , "Shankar Vemulapalli" , "Chan, Chung Ming" , In-Reply-To: <15464.1479.346298.819926@alpha-tli.procket.com> References: <4.3.2.7.2.20020211100227.038f6ae8@dingdong.cisco.com> <4.3.2.7.2.20020210233015.038f2ee8@dingdong.cisco.com> <4.3.2.7.2.20020211100227.038f6ae8@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 08:39:14 +0000 At 09:56 11/02/2002 -0800, Tony Li wrote: >Minimalist viewpoint: the number of end systems out there is vanishingly >small and growing smaller by the day. The thought of an end system at the >end of a point-to-point link then decreases the numbers by another three >orders of magnitude. Yes. I think even in "the good old days" you could count the number of ESs on pt-pt links on one hand :-) Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 09:30:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13064 for ; Tue, 12 Feb 2002 09:30:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CEMPL97906; Tue, 12 Feb 2002 06:22:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BK91L92432 for ; Mon, 11 Feb 2002 12:09:01 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id 8E354CAB77; Mon, 11 Feb 2002 12:14:49 -0800 (PST) Message-ID: <3C680764.AF4927E9@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ken Larmer Cc: Jeff Learman , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Feb 2002 10:03:17 -0800 Content-Transfer-Encoding: 7bit Ken Larmer wrote: > > The reason ISO 10589 requires a router to send ISH packets is that it > > was written for OSI networking (CLNP/ESIS), and the ISH packet is how > > the end systems discover the router. This reason does not apply to > > IS-IS when used for IP only. > > > > Furthermore, receipt of an ISH should not be required to bring an > > IS-IS adjacency to the initializing or up states. I don't have 10589 > > handy, but I don't think it requires receipt of an ISH. If it does, > > I bet it was corrected in a TC. > > I believe that we must be very careful when providing advice from this > working group about implementing Int IS-IS in ways which do not abide by > ISO-10589 and/or RFC-1195. An ISH is used by ISO-10589 for many purposes > other than letting an ES know that it is connected to an IS. An ISH is an > integral part of the PtP initialization process and it also tells the IS > initializing if it is connected to another IS or an ES. > > If an implementer does not properly take into account the affects of not > receiving an ISH or transmitting an ISH, they could surely end up with > scenarios where their implementation will not properly initialize with > another vendor's product under all conceivable conditions. May I suggest > that if there is a consensus that we do not need an ISH, we modify the > specifications accordingly so that everyone implementing Int IS-IS in > accordance with the appropriate specifications will possess a better chance > of achieving full interoperability with other vendors implementing Int IS-IS > in accordance with the same specifications. as Tony stated and was said couple times before already, an according RFC is being encouraged (but not as part of 3-way-hello preferrably since it's a different problem/solution). > BTW, are we sure that we do not need to send ISH PDUs? What about those > very few customer's who are using Integrated IS-IS as a routing protocol to > forward both IP and CLNP packets. When I was at DEC in another lifetime, > there were several customers (both core service providers and enterprise > networks) which were using Int IS-IS for these purposes. > > Just my thoughts? It will be hard to reverse the course of history here. At least 3 deployed implementations are skipping ISHs or working fine without (for IP only of course). It is a more promising course of action to document that (and possible gotchas with it), rather than tyring to enforce ISH processing ... thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 09:30:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13075 for ; Tue, 12 Feb 2002 09:30:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CEMML97890; Tue, 12 Feb 2002 06:22:22 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1BJLYL92214 for ; Mon, 11 Feb 2002 11:21:34 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA19696; Mon, 11 Feb 2002 11:27:04 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Feb 2002 11:27:04 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F7B3@avalon.pluris.com> From: Les Ginsberg To: "'Tony Li'" , Jeff Learman Cc: Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Feb 2002 11:27:01 -0800 The wording associated with sending ISHs and IIHs was clarified in small, but significant ways, in the ISO 10589:2001 draft. Those who are interested, please read the relevant sections. It is still true that a strict interpretation of ISO 10589 requires an ISH to be received before sending IIHs, and therefore a strictly conformant implementation would never bring an adjacency up without first receiving an ISH. As has been discussed previously on this list, some IP only implementations have chosen to not send ISHs and most implementations are "generous" enough to respond to received IIHs even without first receiving an ISH. But, this is not conformant to the only written specification - so I applaud Tony's call for an RFC which documents this protocol change. Perhaps those who chose to ignore the spec would volunteer to write such an RFC?? Les > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Monday, February 11, 2002 9:56 AM > To: Jeff Learman > Cc: Ken Larmer; Shankar Vemulapalli; Chan, Chung Ming; > isis-wg@spider.juniper.net > Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH > > > > | Bottom line, by my interpretation: an IS is required to > send an ISH, > | but it must not expect other routers to send one. > > > Minimalist viewpoint: the number of end systems out there is > vanishingly > small and growing smaller by the day. The thought of an end > system at the > end of a point-to-point link then decreases the numbers by > another three > orders of magnitude. > > This seems like work that could be avoided without dire > consequences. IS's > that wanted to support this certainly could, but the rest of us don't > really gain by it... > > An RFC that said so would be a fine thing... > > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 09:30:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13096 for ; Tue, 12 Feb 2002 09:30:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CEMYL97968; Tue, 12 Feb 2002 06:22:34 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.nortelnetworks.com ([47.237.128.11]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CAEML96266 for ; Tue, 12 Feb 2002 02:14:22 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CAJpL17219; Tue, 12 Feb 2002 11:19:51 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CAJQF19567; Tue, 12 Feb 2002 10:19:27 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS7687D>; Tue, 12 Feb 2002 10:19:51 -0000 Message-ID: <4103264BC8D3D51180B7002048400C450714E0@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Tony Li'" , Jeff Learman Cc: Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3AE.CCEAB5E0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 10:19:48 -0000 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_01C1B3AE.CCEAB5E0 Content-Type: text/plain; charset="iso-8859-1" > > | Bottom line, by my interpretation: an IS is required to > send an ISH, > | but it must not expect other routers to send one. > > > Minimalist viewpoint: the number of end systems out there is > vanishingly > small and growing smaller by the day. The thought of an end > system at the > end of a point-to-point link then decreases the numbers by > another three > orders of magnitude. > > This seems like work that could be avoided without dire > consequences. IS's > that wanted to support this certainly could, but the rest of us don't > really gain by it... > > An RFC that said so would be a fine thing... > > Tony > From draft-ietf-isis-3way-04.txt:- "For example according to ISO 10589 [1] receipt of an ISH will cause an adjacency to go to Initializing state; however receipt of an ISH will have no effect on the three-way state of an adjacency, which remains firmly Down until it receives an IIH from a neighbor that contains the three-way handshaking option." This so nearly makes the statement that you are looking for. I feel that there could/should? be an additional statement in there saying something like "Although ISO 10589 and RFC 1195 mandate the use of ISH PDUs, it has generally been accepted within the industry that ISH PDUs are only needed for connection to OSI End Systems, and therefore need to be supported only by ISs that support CLNP forwarding. Implementors should be aware that ISs are already deployed that do not support CLNP forwarding and both which do send ISH PDUs and which do not sent ISH PDUs. Additionally ISO 10589 states that an adjacency MAY be created on receipt of an ISH or an IIH and so an ISO 10589 compliant implementation SHOULD handle both scenarios.". I would propose that as the three-way-handshake is a discussing adjacency creation anyway, it is a good place to put something like this. I think that I suggested this before, but I don't remember who agreed and who disagreed :) Philip. ------_=_NextPart_001_01C1B3AE.CCEAB5E0 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Question on the usage of ISH and P2PIIH

>
>  | Bottom line, by my interpretation: an IS is required to
> send an ISH,
>  | but it must not expect other routers to send one.
>
>
> Minimalist viewpoint: the number of end systems out there is
> vanishingly
> small and growing smaller by the day.  The thought of an end
> system at the
> end of a point-to-point link then decreases the numbers by
> another three
> orders of magnitude.
>
> This seems like work that could be avoided without dire
> consequences.  IS's
> that wanted to support this certainly could, but the rest of us don't
> really gain by it...
>
> An RFC that said so would be a fine thing...
>
> Tony
>

From draft-ietf-isis-3way-04.txt:-

"For example according to ISO 10589 [1] receipt of an
ISH will cause an adjacency to go to Initializing state; however
receipt of an ISH will have no effect on the three-way state of an
adjacency, which remains firmly Down until it receives an IIH from a
neighbor that contains the three-way handshaking option."

This so nearly makes the statement that you are looking for.  I feel that
there could/should? be an additional statement in there saying something like

"Although ISO 10589 and RFC 1195 mandate the use of ISH PDUs, it has
generally been accepted within the industry that ISH PDUs are only needed
for connection to OSI End Systems, and therefore need to be supported
only by ISs that support CLNP forwarding.  Implementors should be aware
that ISs are already deployed that do not support CLNP forwarding and both
which do send ISH PDUs and which do not sent ISH PDUs.  Additionally ISO
10589 states that an adjacency MAY be created on receipt of an ISH or an IIH
and so an ISO 10589 compliant implementation SHOULD handle both scenarios.".

I would propose that as the three-way-handshake is a discussing adjacency
creation anyway, it is a good place to put something like this.

I think that I suggested this before, but I don't remember who agreed and
who disagreed :)

Philip.

------_=_NextPart_001_01C1B3AE.CCEAB5E0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 09:46:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13585 for ; Tue, 12 Feb 2002 09:46:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CEd1L98172; Tue, 12 Feb 2002 06:39:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.nortelnetworks.com (h11s128a237n47.user.nortelnetworks.com [47.237.128.11]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CEcJL98158 for ; Tue, 12 Feb 2002 06:38:20 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CEi9L26817; Tue, 12 Feb 2002 15:44:09 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CEhiF26621; Tue, 12 Feb 2002 14:43:45 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS774BD>; Tue, 12 Feb 2002 14:44:09 -0000 Message-ID: <4103264BC8D3D51180B7002048400C450714E6@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Tony Przygienda'" , Ken Larmer Cc: Jeff Learman , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3D3.B7B79E20" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 14:44:04 -0000 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_01C1B3D3.B7B79E20 Content-Type: text/plain; charset="iso-8859-1" As a relative newcomer, it took me a long time to realise that there are implementations out there that do not send ISH, and others that do. It just isn't stated anywhere except in the e-mails. There is no point in arguing whether this is right or wrong, it can just be stated as a fact (which it is). A one page RFC stating that some implementations do this, and others do that, and how one should deal with it would be very useful to other newcomers and would improve interop, I would have thought. Maybe someone should write one. Maybe I should write one. The mandatory behaviour is not whether you send ISH or not, but is that you have to deal with either behaviour coming at you. This is what needs to be stated (IMHO). Philip > -----Original Message----- > From: Tony Przygienda [mailto:prz@redback.com] > Sent: 11 February 2002 18:03 > To: Ken Larmer > Cc: Jeff Learman; Shankar Vemulapalli; Chan, Chung Ming; > isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH > > > Ken Larmer wrote: > > > > The reason ISO 10589 requires a router to send ISH > packets is that it > > > was written for OSI networking (CLNP/ESIS), and the ISH > packet is how > > > the end systems discover the router. This reason does > not apply to > > > IS-IS when used for IP only. > > > > > > Furthermore, receipt of an ISH should not be required to bring an > > > IS-IS adjacency to the initializing or up states. I > don't have 10589 > > > handy, but I don't think it requires receipt of an ISH. > If it does, > > > I bet it was corrected in a TC. > > > > I believe that we must be very careful when > providing advice from this > > working group about implementing Int IS-IS in ways which do > not abide by > > ISO-10589 and/or RFC-1195. An ISH is used by ISO-10589 for > many purposes > > other than letting an ES know that it is connected to an > IS. An ISH is an > > integral part of the PtP initialization process and it also > tells the IS > > initializing if it is connected to another IS or an ES. > > > > If an implementer does not properly take into > account the affects of not > > receiving an ISH or transmitting an ISH, they could surely > end up with > > scenarios where their implementation will not properly > initialize with > > another vendor's product under all conceivable conditions. > May I suggest > > that if there is a consensus that we do not need an ISH, we > modify the > > specifications accordingly so that everyone implementing > Int IS-IS in > > accordance with the appropriate specifications will possess > a better chance > > of achieving full interoperability with other vendors > implementing Int IS-IS > > in accordance with the same specifications. > > as Tony stated and was said couple times before already, an > according RFC is being > encouraged (but not as part of 3-way-hello preferrably since > it's a different > problem/solution). > > > BTW, are we sure that we do not need to send ISH > PDUs? What about those > > very few customer's who are using Integrated IS-IS as a > routing protocol to > > forward both IP and CLNP packets. When I was at DEC in > another lifetime, > > there were several customers (both core service providers > and enterprise > > networks) which were using Int IS-IS for these purposes. > > > > Just my thoughts? > > It will be hard to reverse the course of history here. At > least 3 deployed implementations > are skipping ISHs or working fine without (for IP only of > course). It is a more promising > course of action to document that (and possible gotchas with > it), rather than tyring to > enforce ISH processing ... > > thanks > > -- tony > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > ------_=_NextPart_001_01C1B3D3.B7B79E20 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Question on the usage of ISH and P2PIIH

As a relative newcomer, it took me a long time to realise that there are
implementations out there that do not send ISH, and others that do. It just
isn't stated anywhere except in the e-mails.

There is no point in arguing whether this is right or wrong, it can just be
stated as a fact (which it is).

A one page RFC stating that some implementations do this, and others do
that, and how one should deal with it would be very useful to other newcomers
and would improve interop, I would have thought.

Maybe someone should write one.
Maybe I should write one.

The mandatory behaviour is not whether you send ISH or not, but is that you have
to deal with either behaviour coming at you. This is what needs to be stated
(IMHO).

Philip

> -----Original Message-----
> From: Tony Przygienda [mailto:prz@redback.com]
> Sent: 11 February 2002 18:03
> To: Ken Larmer
> Cc: Jeff Learman; Shankar Vemulapalli; Chan, Chung Ming;
> isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH
>
>
> Ken Larmer wrote:
>
> > > The reason ISO 10589 requires a router to send ISH
> packets is that it
> > > was written for OSI networking (CLNP/ESIS), and the ISH
> packet is how
> > > the end systems discover the router.  This reason does
> not apply to
> > > IS-IS when used for IP only.
> > >
> > > Furthermore, receipt of an ISH should not be required to bring an
> > > IS-IS adjacency to the initializing or up states.  I
> don't have 10589
> > > handy, but I don't think it requires receipt of an ISH. 
> If it does,
> > > I bet it was corrected in a TC.
> >
> >         I believe that we must be very careful when
> providing advice from this
> > working group about implementing Int IS-IS in ways which do
> not abide by
> > ISO-10589 and/or RFC-1195. An ISH is used by ISO-10589 for
> many purposes
> > other than letting an ES know that it is connected to an
> IS. An ISH is an
> > integral part of the PtP initialization process and it also
> tells the IS
> > initializing if it is connected to another IS or an ES.
> >
> >         If an implementer does not properly take into
> account the affects of not
> > receiving an ISH or transmitting an ISH, they could surely
> end up with
> > scenarios where their implementation will not properly
> initialize with
> > another vendor's product under all conceivable conditions.
> May I suggest
> > that if there is a consensus that we do not need an ISH, we
> modify the
> > specifications accordingly so that everyone implementing
> Int IS-IS in
> > accordance with the appropriate specifications will possess
> a better chance
> > of achieving full interoperability with other vendors
> implementing Int IS-IS
> > in accordance with the same specifications.
>
> as Tony stated and was said couple times before already, an
> according RFC is being
> encouraged (but not as part of 3-way-hello preferrably since
> it's a different
> problem/solution).
>
> >         BTW, are we sure that we do not need to send ISH
> PDUs? What about those
> > very few customer's who are using Integrated IS-IS as a
> routing protocol to
> > forward both IP and CLNP packets. When I was at DEC in
> another lifetime,
> > there were several customers (both core service providers
> and enterprise
> > networks) which were using Int IS-IS for these purposes.
> >
> >         Just my thoughts?
>
> It will be hard to reverse the course of history here. At
> least 3 deployed implementations
> are skipping ISHs or working fine without (for IP only of
> course). It is a more promising
> course of action to document that (and possible gotchas with
> it), rather than tyring to
> enforce ISH processing ...
>
>     thanks
>
>     -- tony
>
> _______________________________________________
> Isis-wg mailing list  -  Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
>

------_=_NextPart_001_01C1B3D3.B7B79E20-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 10:12:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14585 for ; Tue, 12 Feb 2002 10:12:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CF51L98326; Tue, 12 Feb 2002 07:05:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bart.cwnt.com ([192.116.246.129]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CF4aL98311 for ; Tue, 12 Feb 2002 07:04:36 -0800 (PST) (envelope-from amir@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1B3D7.67B65BFC" Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt Message-ID: X-MS-Has-Attach: yes Thread-Topic: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt Thread-Index: AcGz12et7aAjwKyfRxmaOggn7uzljg== From: "Amir Hermelin" To: "ISIS-wg (E-mail)" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 17:10:28 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B3D7.67B65BFC Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, here's a new version of the draft. The main change is the merge between = the methods to advertise all types of link-state information in extended = LSPs. Therefore Operation Mode 2 changed quite a bit. The newly proposed = TLVs changed from two to one, and its encoding changed as well. Also, = some explanation were clarified. This just about covers all the previous requests from the wg. Please = read and post your comments and suggestions. Thanks. Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. -- Amir Hermelin Charlotte's Web Networks Inc. ------_=_NextPart_001_01C1B3D7.67B65BFC Content-Type: text/plain; name="draft-hermelin-ext-lsp-frags-03.txt" Content-Description: draft-hermelin-ext-lsp-frags-03.txt Content-Disposition: attachment; filename="draft-hermelin-ext-lsp-frags-03.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBbWlyIEhlcm1lbGluDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDaGFybG90dGUncyBXZWIgTmV0d29ya3MNCkV4cGlyYXRpb24g RGF0ZTogQXVndXN0IDIwMDINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFN0ZWZhbm8gUHJldmlkaQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNaWtlIFNoYW5kDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENp c2NvIFN5c3RlbXMNCg0KICAgIEV4dGVuZGluZyB0aGUgTnVtYmVyIG9mIElTLUlTIExTUCBGcmFn bWVudHMgQmV5b25kIHRoZSAyNTYgTGltaXQNCg0KICAgICAgICAgICAgICAgICAgZHJhZnQtaGVy bWVsaW4tZXh0LWxzcC1mcmFncy0wMy50eHQNCg0KDQpTdGF0dXMNCg0KICAgVGhpcyBkb2N1bWVu dCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQog ICBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIEludGVybmV0 LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5n DQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBz LiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5n IGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVy bmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJ bnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3Jn L2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQg U2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQg Tk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtC Q1AxNF0uDQoNCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNo YW5pc20gdGhhdCBhbGxvd3MgYSBzeXN0ZW0gdG8gb3JpZ2luYXRlDQogICBtb3JlIHRoYW4gMjU2 IExTUCBmcmFnbWVudHMsIGEgbGltaXQgc2V0IGJ5IHRoZSBvcmlnaW5hbCBJbnRlcm1lZGlhdGUN CiAgIFN5c3RlbSB0byBJbnRlcm1lZGlhdGUgU3lzdGVtIChJUy1JUykgUm91dGluZyBwcm90b2Nv bCwgYXMgZGVzY3JpYmVkDQogICBpbiBJU08gMTA1ODkuICBUaGlzIG1lY2hhbmlzbSBjYW4gYmUg dXNlZCBpbiBJUC1vbmx5LCBPU0ktb25seSwgYW5kDQogICBkdWFsIHJvdXRlcnMuDQoNCg0KDQoN Cg0KQS4gSGVybWVsaW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwMiAgICAgICAg ICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgZHJhZnQtaGVybWVsaW4t ZXh0LWxzcC1mcmFncy0wMy50eHQgICAgIEZlYnJ1YXJ5IDIwMDINCg0KDQoxLiAgSW50cm9kdWN0 aW9uDQoNCiAgIEluIHRoZSBJUy1JUyBwcm90b2NvbCwgYSBzeXN0ZW0gZmxvb2RzIGl0cyBsaW5r LXN0YXRlIGluZm9ybWF0aW9uIGluDQogICBMaW5rIFN0YXRlIFByb3RvY29sIERhdGEgVW5pdHMs IG9yIExTUHMgZm9yIHNob3J0LiAgVGhlc2UgbG9naWNhbA0KICAgTFNQcyBjYW4gYmVjb21lIHF1 aXRlIGxhcmdlLCB0aGVyZWZvcmUgdGhlIHByb3RvY29sIHNwZWNpZmllcyBhIG1lYW5zDQogICBv ZiBmcmFnbWVudGluZyB0aGlzIGluZm9ybWF0aW9uIGludG8gbXVsdGlwbGUgTFNQIGZyYWdtZW50 cy4gIFRoZQ0KICAgbnVtYmVyIG9mIGZyYWdtZW50cyBhIHN5c3RlbSBjYW4gZ2VuZXJhdGUgaXMg bGltaXRlZCBieSBJU08gMTA1ODkNCiAgIFtJU0lTLUlTT10gdG8gMjU2IGZyYWdtZW50cywgd2hl cmUgZWFjaCBmcmFnbWVudCdzIHNpemUgaXMgYWxzbw0KICAgbGltaXRlZC4gIEhlbmNlLCB0aGVy ZSBpcyBhIGxpbWl0IG9uIHRoZSBhbW91bnQgb2YgbGluay1zdGF0ZQ0KICAgaW5mb3JtYXRpb24g YSBzeXN0ZW0gY2FuIGdlbmVyYXRlLg0KDQogICBBIG51bWJlciBvZiBmYWN0b3JzIGNhbiBjb250 cmlidXRlIHRvIGV4Y2VlZGluZyB0aGlzIGxpbWl0Og0KICAgICAtICBJbnRyb2R1Y3Rpb24gb2Yg bmV3IFRMVnMgYW5kIHN1Yi1UTFZzIHRvIGJlIGluY2x1ZGVkIGluIExTUHMuDQogICAgIC0gIFRo ZSB1c2Ugb2YgTFNQcyB0byBwcm9wYWdhdGUgdmFyaW91cyB0eXBlcyBvZiBpbmZvcm1hdGlvbiAo c3VjaA0KICAgICBhcyB0cmFmZmljLWVuZ2luZWVyaW5nIGluZm9ybWF0aW9uKS4NCiAgICAgLSAg VGhlIGdyb3dpbmcgc2l6ZSBvZiByb3V0ZSB0YWJsZXMgYW5kIEFTIHRvcG9sb2dpZXMuDQogICAg IC0gIEZpbmVyIGdyYW51bGFyaXR5IHJvdXRpbmcsIGFuZCB0aGUgYWJpbGl0eSB0byBpbmplY3Qg ZXh0ZXJuYWwNCiAgICAgcm91dGVzIGludG8gYXJlYXMgW0RPTUFJTi1XSURFXS4NCiAgICAgLSAg T3RoZXIgZW1lcmdpbmcgdGVjaG5vbG9naWVzLCBzdWNoIGFzIG9wdGljYWwsIElQdjYsIGV0Yy4N Cg0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgbWVjaGFuaXNtcyB0byByZWxheCB0aGUgbGlt aXQgb24gdGhlIG51bWJlcg0KICAgb2YgTFNQIGZyYWdtZW50cy4NCg0KDQoxLjEgIERlZmluaXRp b25zIG9mIENvbW1vbmx5IFVzZWQgVGVybXMNCg0KICAgVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGRl ZmluaXRpb25zIGZvciB0ZXJtcyB0aGF0IGFyZSB1c2VkIHRocm91Z2hvdXQNCiAgIHRoZSB0ZXh0 Lg0KDQogICAgIE9yaWdpbmF0aW5nIFN5c3RlbQ0KICAgICAgICBBIHJvdXRlciBydW5uaW5nIHRo ZSBJUy1JUyBwcm90b2NvbC4NCg0KICAgICBPcmlnaW5hbCBzeXN0ZW0taWQNCiAgICAgICAgVGhl IHN5c3RlbS1pZCBvZiBhbiBPcmlnaW5hdGluZyBTeXN0ZW0uDQoNCiAgICAgRXh0ZW5kZWQgc3lz dGVtLWlkDQogICAgICAgIEFuIGFkZGl0aW9uYWwgc3lzdGVtLWlkIHRoYXQgaXMgYXNzaWduZWQg YnkgdGhlIG5ldHdvcmsNCiAgICAgICAgYWRtaW5pc3RyYXRvci4gIEVhY2ggZXh0ZW5kZWQgc3lz dGVtLWlkIGFsbG93cyBnZW5lcmF0aW9uIG9mIDI1Ng0KICAgICAgICBhZGRpdGlvbmFsLCBvciBl eHRlbmRlZCwgTFNQIGZyYWdtZW50cy4gIFRoZSBleHRlbmRlZCBzeXN0ZW0taWQsDQogICAgICAg IGxpa2UgdGhlIG9yaWdpbmFsIHN5c3RlbS1pZCwgbXVzdCBiZSB1bmlxdWUgdGhyb3VnaG91dCB0 aGUNCiAgICAgICAgcm91dGluZyBkb21haW4uDQoNCiAgICAgVmlydHVhbCBTeXN0ZW0NCiAgICAg ICAgVGhlIHN5c3RlbSwgaWRlbnRpZmllZCBieSBhbiBleHRlbmRlZCBzeXN0ZW0taWQsIGFkdmVy dGlzZWQgYXMNCiAgICAgICAgb3JpZ2luYXRpbmcgdGhlIGV4dGVuZGVkIExTUCBmcmFnbWVudHMu ICBUaGVzZSBmcmFnbWVudHMgc3BlY2lmeQ0KICAgICAgICB0aGUgZXh0ZW5kZWQgc3lzdGVtLWlk IGluIHRoZWlyIExTUCBJRHMuDQoNCg0KDQoNCkEuIEhlcm1lbGluLCBldCBhbC4gICAgICAgIEV4 cGlyZXMgQXVndXN0IDIwMDIgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQg RHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDMudHh0ICAgICBGZWJydWFy eSAyMDAyDQoNCg0KICAgICBPcmlnaW5hbCBMU1ANCiAgICAgICAgQW4gTFNQIHVzaW5nIHRoZSBv cmlnaW5hbCBzeXN0ZW0taWQgaW4gaXRzIExTUCBJRC4NCg0KICAgICBFeHRlbmRlZCBMU1ANCiAg ICAgICAgQW4gTFNQIHVzaW5nIGFuIGV4dGVuZGVkIHN5c3RlbS1pZCBpbiBpdHMgTFNQIElELg0K DQogICAgIExTUCBzZXQNCiAgICAgICAgTG9naWNhbCBMU1AuICBUaGlzIHRlcm0gaXMgdXNlZCBv bmx5IHRvIHJlc29sdmUgdGhlIGFtYmlndWl0eQ0KICAgICAgICBiZXR3ZWVuIGEgbG9naWNhbCBM U1AgYW5kIGFuIExTUCBmcmFnbWVudCwgYm90aCBvZiB3aGljaCBhcmUNCiAgICAgICAgc29tZXRp bWVzIHRlcm1lZCAiTFNQIi4NCg0KICAgICBFeHRlbmRlZCBMU1Agc2V0DQogICAgICAgIEEgZ3Jv dXAgb2YgTFNQIGZyYWdtZW50cyB1c2luZyBhbiBleHRlbmRlZCBzeXN0ZW0taWQsIGFuZA0KICAg ICAgICBvcmlnaW5hdGVkIGJ5IHRoZSBPcmlnaW5hdGluZyBTeXN0ZW0uDQoNCiAgICAgRXh0ZW5z aW9uLWNhcGFibGUgSVMNCiAgICAgICAgQW4gSVMgaW1wbGVtZW50aW5nIHRoaXMgZXh0ZW5zaW9u Lg0KDQoNCjEuMiAgT3BlcmF0aW9uIE1vZGVzDQoNCiAgIFR3byBhZG1pbmlzdHJhdGl2ZSBvcGVy YXRpb24gbW9kZXMgYXJlIHByb3ZpZGVkOg0KDQogICAgICAgLSBPcGVyYXRpb24gTW9kZSAxIHBy b3ZpZGVzIGJlaGF2aW9yIHRoYXQgYWxsb3dzIGltcGxlbWVudGF0aW9ucw0KICAgICAgIHRoYXQg ZG9uJ3Qgc3VwcG9ydCB0aGlzIGV4dGVuc2lvbiwgdG8gY29ycmVjdGx5IHByb2Nlc3MgdGhlDQog ICAgICAgZXh0ZW5kZWQgZnJhZ21lbnQgaW5mb3JtYXRpb24sIHdpdGhvdXQgYW55IG1vZGlmaWNh dGlvbnMuICBUaGlzDQogICAgICAgbW9kZSBoYXMgc29tZSByZXN0cmljdGlvbnMgb24gd2hhdCBt YXkgYmUgYWR2ZXJ0aXNlZCBpbiB0aGUNCiAgICAgICBleHRlbmRlZCBMU1AgZnJhZ21lbnRzLiAg TmFtZWx5LCBvbmx5IGxlYWYgaW5mb3JtYXRpb24gbWF5IGJlDQogICAgICAgYWR2ZXJ0aXNlZCBp biB0aGUgZXh0ZW5kZWQgTFNQcy4NCg0KICAgICAgIC0gT3BlcmF0aW9uIE1vZGUgMiBleHRlbmRz IHRoZSBwcmV2aW91cyBtb2RlIGFuZCByZWxheGVzIGl0cw0KICAgICAgIGFkdmVydGlzZW1lbnQg cmVzdHJpY3Rpb25zLiAgQW55IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gbWF5IGJlDQogICAgICAg YWR2ZXJ0aXNlZCBpbiB0aGUgZXh0ZW5kZWQgTFNQcy4gIEhvd2V2ZXIsIGl0IG1hbmRhdGVzIGEg Y2hhbmdlDQogICAgICAgdG8gdGhlIHdheSBMU1BzIGFyZSBjb25zaWRlcmVkIGR1cmluZyB0aGUg U1BGIGFsZ29yaXRobSwgaW4gYSB3YXkNCiAgICAgICB0aGF0IGlzbid0IGNvbXBhdGlibGUgd2l0 aCBwcmV2aW91cyBpbXBsZW1lbnRhdGlvbnMuDQoNCiAgIFRoZXNlIG1vZGVzIG1heSBiZSBjb25m aWd1cmVkIHBlciBsZXZlbC4gIFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uDQogICB0aGF0IGFuIEwx L0wyIElTIG9wZXJhdGVzIGluIHRoZSBzYW1lIG1vZGUsIGZvciBib3RoIEwxIGFuZCBMMi4NCg0K ICAgUm91dGVycyBNQVkgaW1wbGVtZW50IE9wZXJhdGlvbmFsIE1vZGUgMiB3aXRob3V0IHN1cHBv cnRpbmcgcnVubmluZw0KICAgaW4gT3BlcmF0aW9uYWwgTW9kZSAxLiAgVGhleSB3aWxsIHN0aWxs IGludGVyb3BlcmF0ZSBjb3JyZWN0bHkgd2l0aA0KICAgcm91dGVycyB0aGF0IHN1cHBvcnQgYm90 aCBtb2Rlcy4NCg0KDQoxLjMgIE92ZXJ2aWV3DQoNCiAgIFVzaW5nIGFkZGl0aW9uYWwgc3lzdGVt LWlkcyBhc3NpZ25lZCBieSB0aGUgYWRtaW5pc3RyYXRvciwgdGhlDQoNCg0KDQpBLiBIZXJtZWxp biwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDAyICAgICAgICAgICAgICAgICAgW1Bh Z2UgM10NCgwNCkludGVybmV0IERyYWZ0ICAgICBkcmFmdC1oZXJtZWxpbi1leHQtbHNwLWZyYWdz LTAzLnR4dCAgICAgRmVicnVhcnkgMjAwMg0KDQoNCiAgIE9yaWdpbmF0aW5nIFN5c3RlbSBjYW4g YWR2ZXJ0aXNlIHRoZSBleGNlc3MgbGluay1zdGF0ZSBpbmZvcm1hdGlvbiBpbg0KICAgZXh0ZW5k ZWQgTFNQcyB1bmRlciB0aGVzZSBleHRlbmRlZCBzeXN0ZW0taWRzLiAgSXQgd291bGQgZG8gc28g YXMgaWYNCiAgIG90aGVyIHJvdXRlcnMsIG9yICJWaXJ0dWFsIFN5c3RlbXMiLCB3ZXJlIGFkdmVy dGlzaW5nIHRoaXMNCiAgIGluZm9ybWF0aW9uLiAgVGhlc2UgZXh0ZW5kZWQgTFNQcyB3aWxsIGFs c28gaGF2ZSB0aGUgc3BlY2lmaWVkIGxpbWl0DQogICBvbiB0aGVpciBMU1AgZnJhZ21lbnRzOyBo b3dldmVyLCB0aGUgT3JpZ2luYXRpbmcgU3lzdGVtIG1heSBnZW5lcmF0ZQ0KICAgZXh0ZW5kZWQg TFNQcyB1bmRlciBudW1lcm91cyBWaXJ0dWFsIFN5c3RlbXMuDQoNCiAgIEZvciBPcGVyYXRpb24g TW9kZSAxLCAwLWNvc3QgYWRqYWNlbmNpZXMgYXJlIGFkdmVydGlzZWQgZnJvbSB0aGUNCiAgIE9y aWdpbmF0aW5nIFN5c3RlbSB0byBpdHMgVmlydHVhbCBTeXN0ZW0ocykuICBObyBhZGphY2VuY2ll cyAob3RoZXINCiAgIHRoYW4gYmFjayB0byB0aGUgT3JpZ2luYXRpbmcgU3lzdGVtKSBhcmUgYWR2 ZXJ0aXNlZCBpbiB0aGUgZXh0ZW5kZWQNCiAgIExTUHMuICBBcyBhIGNvbnNlcXVlbmNlLCB0aGUg VmlydHVhbCBTeXN0ZW1zIGFyZSAnc3R1YicsIG1lYW5pbmcgdGhleQ0KICAgY2FuIG9ubHkgYmUg cmVhY2hlZCB0aHJvdWdoIHRoZWlyIE9yaWdpbmF0aW5nIFN5c3RlbS4gIFRoZXJlZm9yZSwNCiAg IG9sZGVyIGltcGxlbWVudGF0aW9ucyBkbyBub3QgbmVlZCBtb2RpZmljYXRpb25zIGluIG9yZGVy IHRvIGNvcnJlY3RseQ0KICAgcHJvY2VzcyB0aGVzZSBleHRlbmRlZCBMU1BzLg0KDQogICBGb3Ig Ym90aCBtb2RlcywgZWFjaCBMU1AgKHNldCkgY3JlYXRlZCBieSBhIG5vZGUgd2lsbCBjb250YWlu IG9uIGl0cw0KICAgZnJhZ21lbnQtMCBhIG5ldyBUTFYgKElTIEFsaWFzIElEIFRMVikgdGhhdCBj b250YWlucyB0aGUgT3JpZ2luYWwNCiAgIHN5c3RlbS1pZCBhbmQgUE4gTnVtYmVyIG9mIHRoZSAo Zmlyc3QpIExTUCBjcmVhdGVkIGJ5IHRoZSByb3V0ZXIuDQogICBFeHRlbnNpb24tY2FwYWJsZSBJ U3MgY2FuIHRoZW4gdXNlIHRoaXMgaW5mb3JtYXRpb24gYW5kIHN0b3JlIHRoZQ0KICAgb3JpZ2lu YWwgYW5kIGV4dGVuZGVkIExTUHMgYXMgb25lIGxvZ2ljYWwgTFNQLg0KDQoNCjIuMCAgSVMgQWxp YXMgSUQgVExWIChJUy1BKQ0KDQogICBUaGUgcHJvcG9zZWQgSVMtQSBUTFYgYWxsb3dzIGV4dGVu c2lvbi1jYXBhYmxlIElTcyB0byByZWNvZ25pemUgYWxsDQogICBMU1BzIG9mIGFuIE9yaWdpbmF0 aW5nIFN5c3RlbSwgYW5kIGNvbWJpbmUgdGhlIG9yaWdpbmFsIGFuZCBleHRlbmRlZA0KICAgTFNQ cyBmb3IgdGhlIHB1cnBvc2Ugb2YgU1BGIGNvbXB1dGF0aW9uLg0KDQogICBUaGUgSVMgQWxpYXMg SUQgVExWIGlzIHR5cGUgMjQsIGFuZCBjb250YWlucyBhIG5ldyBkYXRhIHN0cnVjdHVyZSwNCiAg IGNvbnNpc3Rpbmcgb2Y6DQogICAgIDcgb2N0ZXRzIG9mIHN5c3RlbSBJZCBhbmQgcHNldWRvbm9k ZSBudW1iZXINCiAgICAgMSBvY3RldCBvZiBsZW5ndGggb2Ygc3ViLVRMVnMNCiAgICAgMC0yNDcg b2N0ZXRzIG9mIHN1Yi1UTFZzLA0KICAgICAgICB3aGVyZSBlYWNoIHN1Yi1UTFYgY29uc2lzdHMg b2YgYSBzZXF1ZW5jZSBvZg0KICAgICAgICAgICAxIG9jdGV0IG9mIHN1Yi10eXBlDQogICAgICAg ICAgIDEgb2N0ZXQgb2YgbGVuZ3RoDQogICAgICAgICAgIDAtMjQ1IG9jdGV0cyBvZiB2YWx1ZQ0K DQogICBXaXRob3V0IHN1Yi1UTFZzLCB0aGlzIHN0cnVjdHVyZSBjb25zdW1lcyA4IG9jdGV0cyBw ZXIgTFNQIHNldC4gIFRoaXMNCiAgIFRMViBNVVNUIGJlIGluY2x1ZGVkIGluIGZyYWdtZW50IDAg b2YgZXZlcnkgTFNQIHNldCBiZWxvbmdpbmcgdG8gYW4NCiAgIE9yaWdpbmF0aW5nIFN5c3RlbS4N Cg0KDQozLjAgIEdlbmVyYXRpbmcgTFNQcw0KDQozLjEgIEJvdGggT3BlcmF0aW9uIE1vZGVzDQoN Cg0KDQoNCkEuIEhlcm1lbGluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDIgICAg ICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgIGRyYWZ0LWhlcm1l bGluLWV4dC1sc3AtZnJhZ3MtMDMudHh0ICAgICBGZWJydWFyeSAyMDAyDQoNCg0KICAgVW5kZXIg Ym90aCBtb2RlcywgdGhlIE9yaWdpbmF0aW5nIFN5c3RlbSBNVVNUIGluY2x1ZGUgaW5mb3JtYXRp b24NCiAgIGJpbmRpbmcgdGhlIE9yaWdpbmFsIExTUCBhbmQgdGhlIEV4dGVuZGVkIG9uZXMuICBJ dCBjYW4gZG8gdGhpcyBzaW5jZQ0KICAgaXQgaXMgdHJpdmlhbGx5IGFuIGV4dGVuc2lvbi1jYXBh YmxlIElTLiAgVGhpcyBpcyB0byBlbnN1cmUgb3RoZXINCiAgIHJvdXRlcnMgY29ycmVjdGx5IHBy b2Nlc3MgdGhlIGV4dHJhIGluZm9ybWF0aW9uIGluIHRoZWlyIFNQRg0KICAgY2FsY3VsYXRpb24u ICBUaGlzIGJpbmRpbmcgaXMgYWR2ZXJ0aXNlZCB2aWEgYSBuZXcgSVMgQWxpYXMgSUQgVExWLA0K ICAgd2hpY2ggaXMgYWR2ZXJ0aXNlZCBpbiBhbGwgZnJhZ21lbnQgMCwgd2hldGhlciB0aGV5IGJl bG9uZyB0byB0aGUNCiAgIG9yaWdpbmFsIExTUCBvciB0byB0aGUgZXh0ZW5kZWQgb25lcy4NCg0K ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwg IE9yaWdpbmF0aW5nIFN5c3RlbSAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICBzeXN0 ZW0taWQgICA9IFMgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgaXMtYWxpYXMt aWQgPSBTICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICggIGV4dGVuZGVkIHN5 c3RlbS1pZHMgPSBTJywgIFMnJyAgKSAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgVmlydHVhbCBTeXN0ZW0gICB8ICAgICB8ICBW aXJ0dWFsIFN5c3RlbSAgIHwNCiAgIHwgIHN5c3RlbS1pZCAgID0gUycgfCAgICAgfCAgc3lzdGVt LWlkICAgPSBTJyd8DQogICB8ICBpcy1hbGlhcy1pZCA9IFMgIHwgICAgIHwgIGlzLWFsaWFzLWlk ID0gUyAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICArLS0tLS0tLS0tLS0tLS0tLS0t LSsNCg0KICAgRmlndXJlIDEuIEFkdmVydGlzaW5nIGJpbmRpbmcgYmV0d2VlbiBhbGwgb2YgYSBz eXN0ZW0ncyBMU1BzIChib3RoDQogICBtb2RlcykNCg0KICAgV2hlbiBuZXcgZXh0ZW5kZWQgTFNQ IGZyYWdtZW50cyBhcmUgZ2VuZXJhdGVkLCB0aGVzZSBmcmFnbWVudHMgc2hvdWxkDQogICBiZSBn ZW5lcmF0ZWQgYXMgc3BlY2lmaWVkIGluIElTTyAxMDU4OSBbSVNJUy1JU09dLiAgRnVydGhlcm1v cmUsIGENCiAgIHN5c3RlbSBTSE9VTEQgdHJlYXQgaXRzIGV4dGVuZGVkIExTUHMgdGhlIHNhbWUg YXMgaXQgdHJlYXRzIGl0cw0KICAgb3JpZ2luYWwgTFNQcywgd2l0aCB0aGUgZXhjZXB0aW9ucyBu b3RlZCBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLg0KICAgU3BlY2lmaWNhbGx5LCBjcmVhdGlu ZywgZmxvb2RpbmcsIHJlbmV3aW5nLCBwdXJnaW5nIGFuZCBhbGwgb3RoZXINCiAgIG9wZXJhdGlv bnMgYXJlIHNpbWlsYXIgZm9yIGJvdGggb3JpZ2luYWwgYW5kIGV4dGVuZGVkIExTUHMsIHVubGVz cw0KICAgc3RhdGVkIG90aGVyd2lzZS4gIFRoZSBleHRlbmRlZCBMU1BzIHdpbGwgdXNlIG9uZSBv ZiB0aGUgZXh0ZW5kZWQNCiAgIHN5c3RlbS1pZHMgY29uZmlndXJlZCBmb3IgdGhlIHJvdXRlciwg aW4gdGhlaXIgTFNQIElELg0KDQogICBFeHRlbmRlZCBMU1BzIGZyYWdtZW50IHplcm8gc2hvdWxk IGJlIHJlZ2FyZGVkIGluIHRoZSBzYW1lIHNwZWNpYWwNCiAgIG1hbm5lciBhcyBzcGVjaWZpZWQg aW4gMTA1ODkgZm9yIExTUHMgd2l0aCBudW1iZXIgemVybywgYW5kIHNob3VsZA0KICAgaW5jbHVk ZSB0aGUgc2FtZSB0eXBlIG9mIGV4dHJhIGluZm9ybWF0aW9uIGFzIHNwZWNpZmllZCBpbiAxMDU4 OSBhbmQNCiAgIFJGQyAxMTk1IFtJU0lTLUlQXS4gIFNvLCBmb3IgZXhhbXBsZSwgd2hlbiBhIHN5 c3RlbSByZWlzc3VlcyBpdHMgTFNQDQogICBmcmFnZW1udCB6ZXJvIGR1ZSB0byBhbiBhcmVhIGFk ZHJlc3MgY2hhbmdlLCBpdCBzaG91bGQgcmVpc3N1ZSBhbGwNCiAgIGV4dGVuZGVkIExTUHMgZnJh Z21lbnQgemVybyBhcyB3ZWxsLg0KDQogICBBbiBleHRlbmRlZCBMU1AgZnJhZ21lbnQgemVybyBN VVNUIGJlIGdlbmVyYXRlZCBmb3IgZXZlcnkgZXh0ZW5kZWQNCiAgIExTUCBzZXQsIHRvIGFsbG93 IGEgcm91dGVyJ3MgU1BGIGNhbGN1bGF0aW9uIHRvIGNvbnNpZGVyIHRob3NlDQogICBmcmFnbWVu dHMgaW4gdGhhdCBzZXQuDQoNCg0KMy4xLjEgIFRoZSBBdHRhY2hlZCBCaXRzDQoNCg0KDQoNCkEu IEhlcm1lbGluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDIgICAgICAgICAgICAg ICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1s c3AtZnJhZ3MtMDMudHh0ICAgICBGZWJydWFyeSAyMDAyDQoNCg0KICAgVGhlIEF0dGFjaGVkIChB VFQpIGJpdHMgU0hPVUxEIGJlIHNldCB0byB6ZXJvIGZvciBhbGwgZm91ciBtZXRyaWMNCiAgIHR5 cGVzLCBvbiBhbGwgZXh0ZW5kZWQgTFNQcy4gIFRoaXMgaXMgZHVlIHRvIHRoZSBmb2xsb3dpbmc6 IGlmIGENCiAgIFZpcnR1YWwgU3lzdGVtIGlzIHJlYWNoYWJsZSwgc28gaXMgaXRzIE9yaWdpbmF0 aW5nIFN5c3RlbS4gIEl0IGlzDQogICBwcmVmZXJhYmxlLCB0aGVuLCB0aGF0IGFuIEwxIElTIGNo b29zZXMgdGhlIE9yaWdpbmF0aW5nIFN5c3RlbSBhbmQNCiAgIG5vdCB0aGUgVmlydHVhbCBTeXN0 ZW0gYXMgaXRzIG5lYXJlc3QgTDIgZXhpdCBwb2ludCwgYXMgY29ubmVjdGl2aXR5DQogICB0byB0 aGUgVmlydHVhbCBTeXN0ZW0gaGFzIGEgaGlnaGVyIHByb2JhYmlsaXR5IG9mIGJlaW5nIGxvc3Qg KGENCiAgIHJlc3VsdCBvZiB0aGUgZXh0ZW5kZWQgTFNQIG5vIGxvbmdlciBiZWluZyBhZHZlcnRp c2VkKS4gIFRoaXMgY291bGQNCiAgIGNhdXNlIHVubmVjZXNzYXJ5IGNvbXB1dGF0aW9ucyBvbiBz b21lIGltcGxlbWVudGF0aW9ucy4NCg0KDQozLjEuMiAgVGhlIFBhcnRpdGlvbiBSZXBhaXIgQml0 DQoNCiAgIFRoZSBQYXJ0aXRpb24gUmVwYWlyIChQKSBiaXQgU0hPVUxEIGJlIHNldCB0byB6ZXJv IG9uIGFsbCBleHRlbmRlZA0KICAgTFNQcy4gIFRoaXMgaXMgZm9yIHRoZSBzYW1lIHJlYXNvbnMg YXMgZm9yIHRoZSBBdHRhY2hlZCBiaXRzLg0KDQoNCjMuMS4zICBFUyBOZWlnaGJvcnMgVExWDQoN CiAgIElTTyAxMDU4OSBbSVNJUy1JU09dIHNlY3Rpb24gNy4zLjcgc3BlY2lmaWVzIGluc2VydGlu ZyBhbiBFUyBOZWlnaGJvcg0KICAgVExWIGluIEwxIExTUHMsIHdpdGggdGhlIHN5c3RlbSBJRCBv ZiB0aGUgcm91dGVyLiAgUkZDIDExOTUgW0lTSVMtSVBdDQogICByZWxpZXZlcyBJUC1vbmx5IHJv dXRlcnMgb2YgdGhpcyByZXF1aXJlbWVudC4gIEhvd2V2ZXIsIGZvciByb3V0ZXJzDQogICB0aGF0 IGRvIGluc2VydCB0aGlzIEVTTiBUTFYgaW4gTDEgTFNQcyAod2hldGhlciBJUC1vbmx5IG9yIE9T SS0NCiAgIGNhcGFibGUpLCB0aGVuIGluIGFuIGV4dGVuZGVkIExTUCwgdGhlIEVTTiBUTFYgc2hv dWxkIGluY2x1ZGUgdGhlDQogICByZWxldmFudCBleHRlbmRlZCBzeXN0ZW0taWQuICBGdXJ0aGVy bW9yZSwgT1NJLWNhcGFibGUgcm91dGVycyBzaG91bGQNCiAgIGFjY2VwdCBwYWNrZXRzIGRlc3Rp bmVkIGZvciB0aGlzIGV4dGVuZGVkIHN5c3RlbS1pZC4NCg0KDQozLjIgIE9wZXJhdGlvbiBNb2Rl IDEgQWRkaXRpb25zDQoNCiAgIFRoZSBmb2xsb3dpbmcgYWRkaXRpb25zIGFwcGx5IG9ubHkgdG8g cm91dGVycyBnZW5lcmF0aW5nIExTUHMgaW4gTW9kZQ0KICAgMS4gIFJvdXRlcnMsIHdoaWNoIGFy ZSBjb25maWd1cmVkIHRvIG9wZXJhdGUgaW4gT3BlcmF0aW9uIE1vZGUgMiwNCiAgIFNIT1VMRCBO T1QgYXBwbHkgdGhlc2UgYWRkaXRpb25zIHRvIHRoZWlyIGFkdmVydGlzZW1lbnRzLg0KDQogICBV bmRlciBPcGVyYXRpb24gTW9kZSAxLCBhZGphY2VuY2llcyBiZXR3ZWVuIHRoZSBPcmlnaW5hbCBT eXN0ZW0gYW5kDQogICBpdHMgVmlydHVhbCBTeXN0ZW1zIGFyZSBhZHZlcnRpc2VkIHVzaW5nIHRo ZSBzdGFuZGFyZCBuZWlnaGJvciBUTFZzLg0KICAgVGhlIG1ldHJpYyBmb3IgdGhlc2UgY29ubmVj dGlvbnMgTVVTVCBiZSB6ZXJvLCBzaW5jZSB0aGUgY29zdCBvZg0KICAgcmVhY2hpbmcgYSBWaXJ0 dWFsIFN5c3RlbSBpcyB0aGUgc2FtZSBhcyB0aGUgY29zdCBvZiByZWFjaGluZyBpdHMNCiAgIE9y aWdpbmF0aW5nIFN5c3RlbS4NCg0KICAgVG8gb2xkZXIgaW1wbGVtZW50YXRpb25zLCBWaXJ0dWFs IFN5c3RlbXMgd291bGQgYXBwZWFyIHJlYWNoYWJsZSBvbmx5DQogICB0aHJvdWdoIHRoZWlyIE9y aWdpbmF0aW5nIFN5c3RlbSwgaGVuY2UgbG9zcyBvZiBjb25uZWN0aXZpdHkgdG8gdGhlDQogICBP cmlnaW5hdGluZyBTeXN0ZW0gbWVhbnMgbG9zcyBvZiBjb25uZWN0aXZpdHkgdG8gYWxsIG9mIGl0 cw0KICAgaW5mb3JtYXRpb24sIGluY2x1ZGluZyB0aGF0IGFkdmVydGlzZWQgaW4gaXRzIGV4dGVu ZGVkIExTUHMuDQogICBGdXJ0aGVybW9yZSwgdGhlIGNvc3Qgb2YgcmVhY2hpbmcgaW5mb3JtYXRp b24gYWR2ZXJ0aXNlZCBpbiBub24tDQogICBleHRlbmRlZCBMU1BzIGlzIHRoZSBzYW1lIGFzIHRo ZSBjb3N0IG9mIHJlYWNoaW5nIGluZm9ybWF0aW9uDQogICBhZHZlcnRpc2VkIGluIHRoZSBuZXcg ZXh0ZW5kZWQgTFNQcywgd2l0aCBhbiBhZGRpdGlvbmFsIGhvcC4NCg0KDQoNCg0KQS4gSGVybWVs aW4sIGV0IGFsLiAgICAgICAgRXhwaXJlcyBBdWd1c3QgMjAwMiAgICAgICAgICAgICAgICAgIFtQ YWdlIDZdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgZHJhZnQtaGVybWVsaW4tZXh0LWxzcC1mcmFn cy0wMy50eHQgICAgIEZlYnJ1YXJ5IDIwMDINCg0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgT3JpZ2luYXRpbmcgU3lzdGVtICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHN5c3RlbS1pZCAgID0gUyAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICB8ICBpcy1hbGlhcy1pZCA9IFMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgfCAgKCAgZXh0ZW5kZWQgc3lzdGVtLWlkcyA9IFMnLCAgUycnICApICAg ICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICAgICAgICAgfCAgICAvXCAgICAgICAgICAgICAgICAgICAgfCAgICAvXA0KICAgY29zdD0w IHwgICAgfGNvc3Q9bWF4LTEgICAgY29zdD0wIHwgICAgfGNvc3Q9bWF4LTENCiAgICAgICAgICB8 ICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgIHwNCiAgICAgICAgICBcLyAgIHwgICAgICAg ICAgICAgICAgICAgICBcLyAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0rDQogICB8ICBWaXJ0dWFsIFN5c3RlbSAgIHwgICAgIHwgIFZpcnR1YWwg U3lzdGVtICAgfA0KICAgfCAgc3lzdGVtLWlkICAgPSBTJyB8ICAgICB8ICBzeXN0ZW0taWQgICA9 IFMnJ3wNCiAgIHwgIGlzLWFsaWFzLWlkID0gUyAgfCAgICAgfCAgaXMtYWxpYXMtaWQgPSBTICB8 DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQog ICBGaWd1cmUgMi4gQWR2ZXJ0aXNpbmcgY29ubmVjdGlvbnMgdG8gVmlydHVhbCBTeXN0ZW1zIHVu ZGVyIE9wZXJhdGlvbg0KICAgTW9kZSAxDQoNCiAgIFVuZGVyIE9wZXJhdGlvbiBNb2RlIDEsIG9u bHkgImxlYWYiIGluZm9ybWF0aW9uLCBpLmUuIGluZm9ybWF0aW9uDQogICB0aGF0IHNlcnZlcyBv bmx5IGFzIGxlYXZlcyBpbiBhIHNob3J0ZXN0IHBhdGggdHJlZSwgY2FuIGJlIGFkdmVydGlzZWQN CiAgIGluIGV4dGVuZGVkIExTUHMuDQoNCiAgIFdoZW4gYW4gZXh0ZW5kZWQgTFNQIGJlbG9uZ2lu ZyB0byBleHRlbmRlZCBzeXN0ZW0taWQgUycgaXMgZmlyc3QNCiAgIGNyZWF0ZWQsIHRoZSBvcmln aW5hbCBMU1AgTVVTVCBzcGVjaWZ5IFMnIGFzIGEgbmVpZ2hib3IsIHdpdGggbWV0cmljDQogICBz ZXQgdG8gemVyby4gIFRoaXMgaW4gb3JkZXIgdG8gc2F0aXNmeSB0aGUgdHdvLXdheSBjb25uZWN0 aXZpdHkgY2hlY2sNCiAgIG9uIG90aGVyIHJvdXRlcnMsIGFzIHdlbGwgYXMgdG8gY29uc2lkZXIg dGhlIGNvc3Qgb2YgcmVhY2hpbmcgdGhlDQogICBWaXJ0dWFsIFN5c3RlbSBTJyB0aGUgc2FtZSBh cyB0aGUgY29zdCBvZiByZWFjaGluZyBpdHMgT3JpZ2luYXRpbmcNCiAgIFN5c3RlbS4gIEZ1cnRo ZXJtb3JlLCB0aGUgZXh0ZW5kZWQgTFNQIE1VU1Qgc3BlY2lmeSB0aGUgb3JpZ2luYWwNCiAgIHN5 c3RlbS1pZCBhcyBhIG5laWdoYm9yLCB3aXRoIG1ldHJpYyBzZXQgdG8gKE1heExpbmtNZXRyaWMg LSAxKS4NCiAgIFdoZXJlIHJlbGV2YW50LCB0aGlzIGFkamFjZW5jeSBTSE9VTEQgYmUgY29uc2lk ZXJlZCBhcyBwb2ludC10by0NCiAgIHBvaW50Lg0KDQogICBOb3RlLCB0aGF0IHRoZSByZXN0cmlj dGlvbiBzcGVjaWZpZWQgaW4gSVNPIDEwNTg5IHNlY3Rpb24gNy4yLjUNCiAgIGhvbGRzOiAgaWYg YW4gTFNQIE51bWJlciB6ZXJvIG9mIHRoZSBPcmlnaW5hdGluZyBTeXN0ZW0gaXMgbm90DQogICBw cmVzZW50LCBub25lIG9mIHRoYXQgc3lzdGVtJ3MgbmVpZ2hib3IgZW50cmllcyB3b3VsZCBiZSBw cm9jZXNzZWQNCiAgIGR1cmluZyBTUEYsIGhlbmNlIG5vbmUgb2YgaXRzIGV4dGVuZGVkIExTUHMg d291bGQgYmUgcHJvY2Vzc2VkIGFzDQogICB3ZWxsLg0KDQoNCjMuMi4xICBJUyBOZWlnaGJvcnMg VExWDQoNCiAgIEFuIEV4dGVuZGVkIExTUCBtdXN0IHNwZWNpZnkgb25seSB0aGUgT3JpZ2luYXRp bmcgU3lzdGVtIGFzIGENCiAgIG5laWdoYm9yLCB3aXRoIHRoZSBtZXRyaWMgc2V0IHRvIChNYXhM aW5rTWV0cmljIC0gMSkuICBXaGVyZQ0KICAgcmVsZXZhbnQsIHRoaXMgYWRqYWNlbmN5IHNob3Vs ZCBiZSBjb25zaWRlcmVkIGFzIHBvaW50LXRvLXBvaW50Lg0KICAgT3RoZXIgbmVpZ2hib3JzIE1V U1QgTk9UIGJlIHNwZWNpZmllZCBpbiBhbiBFeHRlbmRlZCBMU1AsIGJlY2F1c2UNCiAgIHRob3Nl IG90aGVyIG5laWdoYm9ycyB3b3VsZCBvbmx5IHNwZWNpZnkgdGhlIE9yaWdpbmF0aW5nIFN5c3Rl bSBhbmQNCg0KDQoNCkEuIEhlcm1lbGluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDIw MDIgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgIGRyYWZ0 LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDMudHh0ICAgICBGZWJydWFyeSAyMDAyDQoNCg0KICAg bm90IHRoZSBleHRlbmRlZCBzeXN0ZW0sIGFuZCBoZW5jZSB3b3VsZCBub3Qgc2F0aXNmeSB0aGUg YmktDQogICBkaXJlY3Rpb25hbGl0eSBjaGVjayBpbiB0aGUgU1BGIGNvbXB1dGF0aW9uLg0KDQoN CjQuICBQdXJnaW5nIEV4dGVuZGVkIExTUCBGcmFnbWVudHMNCg0KICAgSVNPIDEwNTg5IFtJU0lT LUlTT10gc2VjdGlvbiA3LjMuNC40IG5vdGUgMjEgc3VnZ2VzdHMgdGhhdCBhbg0KICAgaW1wbGVt ZW50YXRpb24ga2VlcHMgdGhlIG51bWJlciBvZiBMU1AgZnJhZ21lbnRzIHdpdGhpbiBhIGNlcnRh aW4NCiAgIGxpbWl0IGJhc2VkIG9uIHRoZSBvcHRpbWFsIChtaW5pbWFsKSBudW1iZXIgb2YgZnJh Z21lbnRzIG5lZWRlZC4NCiAgIFNlY3Rpb24gNy4zLjQuNiBhbHNvIHJlY29tbWVuZHMgdGhhdCBh biBJUyBwdXJnZSBpdHMgZW1wdHkgTFNQcyB0bw0KICAgY29uc2VydmUgcmVzb3VyY2VzLiAgVGhl c2UgcmVjb21tZW5kYXRpb25zIGhvbGQgZm9yIHRoZSBleHRlbmRlZCBMU1ANCiAgIGZyYWdtZW50 cyBhcyB3ZWxsLiAgSG93ZXZlciwgYW4gZXh0ZW5kZWQgTFNQIGZyYWdtZW50IHplcm8gc2hvdWxk IG5vdA0KICAgYmUgcHVyZ2VkIHVudGlsIGFsbCBvZiB0aGUgZnJhZ21lbnRzIGluIGl0cyBzZXQg KGkuZS4gYmVsb25naW5nIHRvIGENCiAgIHBhcnRpY3VsYXIgZXh0ZW5kZWQgc3lzdGVtLWlkKSwg YXJlIGVtcHR5IGFzIHdlbGwuICBUaGlzIGlzIHRvIGVuc3VyZQ0KICAgaW1wbGVtZW50YXRpb25z IGNvbnNpZGVyIHRoZSBmcmFnbWVudHMgaW4gdGhlaXIgU1BGIGNvbXB1dGF0aW9ucywgYXMNCiAg IHNwZWNpZmllZCBpbiBzZWN0aW9uIDcuMi41Lg0KDQogICBJbiBPcGVyYXRpb25hbCBNb2RlIDEs IHdoZW4gYWxsIHRoZSBleHRlbmRlZCBMU1AgZnJhZ21lbnRzIG9mIGENCiAgIHBhcnRpY3VsYXIg ZXh0ZW5kZWQgc3lzdGVtLWlkIFMnIGhhdmUgYmVlbiBwdXJnZWQsIHRoZSBPcmlnaW5hdGluZw0K ICAgU3lzdGVtIFNIT1VMRCByZW1vdmUgdGhlIG5laWdoYm9yIGluZm9ybWF0aW9uIHRvIFMnIGZy b20gaXRzIG9yaWdpbmFsDQogICBMU1BzLg0KDQoNCjUuICBNb2RpZmljYXRpb25zIHRvIExTUCBo YW5kbGluZyBpbiBTUEYNCg0KICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBtb2RpZmljYXRpb25z IHRvIHRoZSB3YXkgZXh0ZW5zaW9uLWNhcGFibGUgSVNzDQogICBoYW5kbGUgTFNQcyBmb3IgdGhl IFNQRiBjb21wdXRhdGlvbi4NCg0KICAgV2hlbiBjb25zaWRlcmluZyBMU1BzIG9mIGFuIGV4dGVu c2lvbi1jYXBhYmxlIElTIChpZGVudGlmaWVkIGJ5IHRoZQ0KICAgaW5jbHVzaW9uIG9mIHRoZSBJ UyBBbGlhcyBJRCBUTFYpLCB0aGUgb3JpZ2luYWwgYW5kIGV4dGVuZGVkIExTUHMgYXJlDQogICBj b21iaW5lZCB0byBmb3JtIG9uZSBsYXJnZSBsb2dpY2FsIExTUC4gIElmIHRoZSBMU1AgYmVsb25n cyB0byBhbiBJUw0KICAgcnVubmluZyBPcGVyYXRpb25hbCBNb2RlIDEsIHRoZXJlIG1pZ2h0IGJl IGFkamFjZW5jaWVzIGJldHdlZW4gdGhlDQogICBvcmlnaW5hbCBhbmQgZXh0ZW5kZWQgTFNQcy4g VGhlc2UgYXJlIHRyaXZpYWxseSBpZ25vcmVkIChzaW5jZSB3aGVuDQogICBwcm9jZXNzaW5nIHRo ZW0gdGhlIGxhcmdlIGxvZ2ljYWwgTFNQIGlzIGFscmVhZHkgb24gUEFUSFMpLCBhbmQNCiAgIGRv ZXNuJ3QgY29tcGxpY2F0ZSB0aGUgU1BGLiAgRnVydGhlcm1vcmUsIHRoaXMgY2hlY2sgc2hvdWxk IGFscmVhZHkNCiAgIGJlIGltcGxlbWVudGVkICh0aGlzIHNjZW5hcmlvIGNvdWxkIG9jY3VyIG9u IGVycm9yLCB3aXRob3V0IHRoaXMNCiAgIGV4dGVuc2lvbikNCg0KICAgSWYgTFNQIGZyYWdtZW50 IDAgb2YgdGhlIG9yaWdpbmFsIExTUCBzZXQgaXMgbWlzc2luZywgYWxsIG9mIHRoZSBMU1BzDQog ICBnZW5lcmF0ZWQgYnkgdGhhdCBPcmlnaW5hdGluZyBTeXN0ZW0gKGV4dGVuZGVkIGFzIHdlbGwp IE1VU1QgTk9UIGJlDQogICBjb25zaWRlcmVkIGluIHRoZSBTUEYuICBUaGF0IGlzLCB0aGUgbGFy Z2UgbG9naWNhbCBMU1AgaXNuJ3QNCiAgIGNvbnNpZGVyZWQgaW4gdGhlIFNQRi4gIElmIGFuIExT UCBmcmFnbWVudCAwIG9mIGFuIGV4dGVuZGVkIExTUCBzZXQNCiAgIGlzIG1pc3NpbmcsIG9ubHkg dGhhdCBMU1Agc2V0IE1VU1QgTk9UIGJlIGNvbnNpZGVyZWQgaW4gdGhlIFNQRi4NCg0KICAgTm90 ZSwgdGhhdCB0aGUgYWJvdmUgYmVoYXZpb3IgaXMgY29uc2lzdGVudCB3aXRoIGhvdyBwcmV2aW91 cw0KICAgaW1wbGVtZW50YXRpb25zIHdpbGwgaW50ZXJwcmV0IE1vZGUgMSBMU1BzLg0KDQoNCg0K DQpBLiBIZXJtZWxpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDAyICAgICAgICAg ICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0IERyYWZ0ICAgICBkcmFmdC1oZXJtZWxpbi1l eHQtbHNwLWZyYWdzLTAzLnR4dCAgICAgRmVicnVhcnkgMjAwMg0KDQoNCjYuICBGb3JtaW5nIEFk amFjZW5jaWVzDQoNCiAgIEl0IHNob3VsZCBiZSBub3RlZCwgdGhhdCBhbiBJUyBNVVNUIHVzZSB0 aGUgc3lzdGVtLWlkIG9mIHRoZSBMU1AgdGhhdA0KICAgd2lsbCBpbmNsdWRlIGEgbmVpZ2hib3Is IHdoZW4gZm9ybWluZyBhbiBhZGphY2VuY3kgd2l0aCB0aGF0DQogICBuZWlnaGJvci4gIFRoYXQg aXMsIGlmIGEgbmVpZ2hib3IgaXMgdG8gYmUgaW5jbHVkZWQgaW4gZXh0ZW5kZWQgTFNQDQogICBT JywgdGhlbiBTJyBzaG91bGQgYmUgdXNlZCBhcyB0aGUgc3lzdGVtLWlkIGluIElTIEhlbGxvcyBb M10gYW5kIElTLQ0KICAgSVMgSGVsbG9zIHdoZW4gZm9ybWluZyBhbiBhZGphY2VuY3kgd2l0aCB0 aGF0IG5laWdoYm9yLiAgVGhpcyBpcw0KICAgcmVnYXJkbGVzcyBvZiB0aGUgT3BlcmF0aW9uYWwg TW9kZS4gIE9mIGNvdXJzZSwgaW4gTW9kZSAxIHRoaXMgbWVhbnMNCiAgIHRoYXQgb25seSB0aGUg b3JpZ2luYWwgc3lzdGVtLWlkIHdpbGwgYmUgdXNlZCB3aGVuIHNlbmRpbmcgaGVsbG9zLg0KDQoN CjcuICBJbnRlcm9wZXJhdGluZyBiZXR3ZWVuIGV4dGVuc2lvbi1jYXBhYmxlIGFuZCBub24tZXh0 ZW5zaW9uLWNhcGFibGUNCiAgIElTcy4NCg0KICAgSW4gb3JkZXIgdG8gY29ycmVjdGx5IGFkdmVy dGlzZSBsaW5rLXN0YXRlIGluZm9ybWF0aW9uIHVuZGVyDQogICBPcGVyYXRpb24gTW9kZSAyLCBh bGwgSVNzIGluIGFuIGFyZWEgbXVzdCBiZSBleHRlbnNpb24tY2FwYWJsZS4NCiAgIEhvd2V2ZXIs IGl0IGlzIHBvc3NpYmxlIHRvIG5vdCB1cGdyYWRlIGV2ZXJ5IHJvdXRlciBpbiB0aGUgbmV0d29y aywNCiAgIGlmIHRoZSBleHRlbmRlZCBpbmZvcm1hdGlvbiBpcyBub3Qgcm91dGluZyBpbmZvcm1h dGlvbiwgYnV0IHJhdGhlcg0KICAgZGF0YSB0aGF0IGlzIG9mIHVzZSB0byBvbmx5IGEgc3Vic2V0 IG9mIHJvdXRlcnMgKGUuZy4gb3B0aWNhbA0KICAgc3dpdGNoZXMgdXNpbmcgSVNJUyBjb3VsZCBj YXJyeSBvcHRpY2FsLXNwZWNpZmljIGluZm9ybWF0aW9uIGluDQogICBleHRlbmRlZCBMU1BzKQ0K DQogICBJdCBpcyBwb3NzaWJsZSB0byB0cmFuc2l0aW9uIGEgbGl2ZSBuZXR3b3JrLCB1c2luZyB0 aGUgZm9sbG93aW5nDQogICBzdGVwczoNCiAgICAgLSBVcGdyYWRlIHRoZSByb3V0ZXJzLCBvbmUt Ynktb25lLCB0byBydW4gdGhpcyBleHRlbnNpb24gaW4NCiAgICAgT3BlcmF0aW9uIE1vZGUgMS4g VGhlIG90aGVyIG5vbi1leHRlbnNpb24tY2FwYWJsZSByb3V0ZXJzIHdpbGwNCiAgICAgaW50ZXJv cGVyYXRlIGNvcnJlY3RseS4NCiAgICAgLSBXaGVuIGFsbCByb3V0ZXJzIGFyZSBleHRlbnNpb24t Y2FwYWJsZSwgY29uZmlndXJlIHRoZW0gb25lLWJ5LW9uZQ0KICAgICB0byBydW4gaW4gT3BlcmF0 aW9uIE1vZGUgMi4gIEFsbCBleHRlbnNpb24tY2FwYWJsZSByb3V0ZXJzDQogICAgIGludGVyb3Bl cmF0ZSBjb3JyZWN0bHksIHJlZ2FyZGxlc3Mgb2Ygd2hhdCBtb2RlIHRoZXkncmUgcnVuIGluLg0K DQoNCjguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IHJhaXNl cyBubyBuZXcgc2VjdXJpdHkgaXNzdWVzIGZvciBJUy1JUy4NCg0KDQo5LiAgQWNrbm93bGVkZ21l bnRzDQoNCiAgIFRoZSBhdXRob3Igd291bGQgbGlrZSB0byB0aGFuayBUb255IExpIGFuZCBSYWRp YSBQZXJsbWFuIGZvciBoZWxwZnVsDQogICBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgb24gdGhl IHN1YmplY3QuDQoNCg0KMTAuICBSZWZlcmVuY2VzDQoNCiAgIFtJU0lTLUlTT10gSVNPIDEwNTg5 LCAiSW50ZXJtZWRpYXRlIFN5c3RlbSB0byBJbnRlcm1lZGlhdGUgU3lzdGVtDQogICBJbnRyYS1E b21haW4gUm91dGVpbmcgRXhjaGFuZ2UgUHJvdG9jb2wgZm9yIHVzZSBpbiBDb25qdW5jdGlvbiB3 aXRoDQoNCg0KDQpBLiBIZXJtZWxpbiwgZXQgYWwuICAgICAgICBFeHBpcmVzIEF1Z3VzdCAyMDAy ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0IERyYWZ0ICAgICBkcmFmdC1o ZXJtZWxpbi1leHQtbHNwLWZyYWdzLTAzLnR4dCAgICAgRmVicnVhcnkgMjAwMg0KDQoNCiAgIHRo ZSBQcm90b2NvbCBmb3IgUHJvdmlkaW5nIHRoZSBDb25uZWN0aW9ubGVzcy1tb2RlIE5ldHdvcmsg U2VydmljZQ0KICAgKElTTyA4NDczKSINCg0KICAgW0lTSVMtSVBdIFJGQyAxMTk1LCAiVXNlIG9m IE9TSSBJUy1JUyBmb3Igcm91dGluZyBpbiBUQ1AvSVAgYW5kIGR1YWwNCiAgIGVudmlyb25tZW50 cyIsIFIuVy4gQ2FsbG9uLCBEZWMuIDE5OTANCg0KICAgW0VTLUlTXSBJU08gOTU0MiwgIkVuZCBT eXN0ZW0gdG8gSW50ZXJtZWRpYXRlIFN5c3RlbSBSb3V0ZWluZw0KICAgRXhjaGFuZ2UgUHJvdG9j b2wgZm9yIFVzZSBpbiBDb25qdW5jdGlvbiB3aXRoIHRoZSBQcm90b2NvbCBmb3INCiAgIFByb3Zp ZGluZyB0aGUgQ29ubmVjdGlvbmxlc3MtTW9kZSBOZXR3b3JrIFNlcnZpY2UgKElTTyA4NDczKSIs IE1hcmNoDQogICAxOTg4DQoNCiAgIFtET01BSU4tV0lERV0gUkZDIDI5NjYsICJEb21haW4td2lk ZSBQcmVmaXggRGlzdHJpYnV0aW9uIHdpdGggVHdvLQ0KICAgTGV2ZWwgSVMtSVMiLCBULiBMaSwg VC4gUHJ6eWdpZW5kYSwgSC4gU21pdCwgT2N0b2JlciAyMDAwDQoNCiAgIFtCQ1AxNF0gUkZDIDIx MTksICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50DQog ICBMZXZlbHMiLCBTLiBCcmFkbmVyLCBNYXJjaCAxOTk3DQoNCiAgIFtJU0lTLUNPREVTXSBXb3Jr IGluIHByb2dyZXNzLCAiUmVzZXJ2ZWQgVExWIENvZGVwb2ludHMgaW4gSVNJUyIsIFQuDQogICBQ cnp5Z2llbmRhDQoNCg0KMTEuICBBdXRob3JzJyBBZGRyZXNzDQoNCiAgIEFtaXIgSGVybWVsaW4g ICAgICAgICAgICAgICAgICAgICAgICBFbWFpbDogYW1pckBjd250LmNvbQ0KICAgQ2hhcmxvdHRl J3MgV2ViIE5ldHdvcmtzLCBJbmMuICAgICAgIFBob25lOiArOTcyIDQgOTU5MjIwMw0KICAgMiBI YSdtYWRhIFN0LiAgICAgICAgICAgICAgICAgICAgICAgIEZheDogICArOTcyIDQgOTU5MzMyNQ0K ICAgUE9CIDY1MA0KICAgWW9rbmVhbSwgMjA2OTINCiAgIElTUkFFTA0KDQoNCiAgIE1pa2UgU2hh bmQsICAgICAgICAgICAgICAgICAgICAgICAgICBFbWFpbDogbXNoYW5kQGNpc2NvLmNvbQ0KICAg Q2lzY28gU3lzdGVtcywgICAgICAgICAgICAgICAgICAgICAgIFBob25lOiArNDQgMDIwIDg4MjQg ODY5MA0KICAgNCwgVGhlIFNxdWFyZSwNCiAgIFN0b2NrbGV5IFBhcmssDQogICBVWEJSSURHRSwN CiAgIE1pZGRsZXNleCwNCiAgIFVCMTEgMUJOLA0KICAgVUsNCg0KDQogICBTdGVmYW5vIFByZXZp ZGkgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IHNwcmV2aWRpQGNpc2NvLmNvbQ0KICAgQ2lz Y28gU3lzdGVtcywgSW5jLiAgICAgICAgICAgICAgICAgIFBob25lOiArMzIgMiA3MDQ2NTkwDQog ICBEZSBLbGVldGxhYW4gNkENCiAgIDE4MzEgRGllZ2VtDQogICBCZWxnaXVtDQoNCg0KDQoNCkEu IEhlcm1lbGluLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDIwMDIgICAgICAgICAgICAg ICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQgRHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1s c3AtZnJhZ3MtMDMudHh0ICAgICBGZWJydWFyeSAyMDAyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkEuIEhlcm1lbGluLCBldCBhbC4gICAgICAgIEV4cGly ZXMgQXVndXN0IDIwMDIgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0K ------_=_NextPart_001_01C1B3D7.67B65BFC-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 13:23:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21077 for ; Tue, 12 Feb 2002 13:23:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CIG0L99081; Tue, 12 Feb 2002 10:16:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CIF9L99069 for ; Tue, 12 Feb 2002 10:15:09 -0800 (PST) (envelope-from cmartin@gnilink.net) Received: by entmail.gnilink.net with Internet Mail Service (5.5.2653.19) id <1D0K1CCT>; Tue, 12 Feb 2002 13:21:03 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2B77@entmail.gnilink.net> From: "Martin, Christian" To: "'Les Ginsberg'" , "'Tony Li'" , Jeff Learman Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 13:21:01 -0500 But, this > is not conformant to the only written specification - so I > applaud Tony's > call for an RFC which documents this protocol change. Perhaps > those who > chose to ignore the spec would volunteer to write such an RFC?? If that is the direction that the group wishes to take, then there are a few other "implementation" hacks that should be documented as well. Externals in L1 LSPs comes immediately to mind. The protocol has been enhanced/changed enough in recent years to warrant a compilation that describes what is deployed in the field, IMHO. 1195 is becoming very outdated - I mean it was published before 1209 - SMDS over IP! Jeez... chris > > Les > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 15:39:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25815 for ; Tue, 12 Feb 2002 15:39:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CKV1L99622; Tue, 12 Feb 2002 12:31:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CKUWL99610 for ; Tue, 12 Feb 2002 12:30:32 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id E8E1E1DCC6E; Tue, 12 Feb 2002 12:36:26 -0800 (PST) Message-ID: <3C695DF4.39063218@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Les Ginsberg Cc: "'Tony Li'" , Jeff Learman , Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH References: <17C81AD1F1FED411991E006008F6D1CA01B3F7B3@avalon.pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 10:24:52 -0800 Content-Transfer-Encoding: 7bit Les Ginsberg wrote: > so I applaud Tony's > call for an RFC which documents this protocol change. Perhaps those who > chose to ignore the spec would volunteer to write such an RFC?? I applaud that, put me on the list of authors pls. who else? ;-) thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 16:06:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27356 for ; Tue, 12 Feb 2002 16:06:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CKwhL99771; Tue, 12 Feb 2002 12:58:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CKsnL99740 for ; Tue, 12 Feb 2002 12:54:49 -0800 (PST) (envelope-from mbartell@cisco.com) Received: from MBARTELL-W2K.cisco.com (mbartell-w2k.cisco.com [64.101.142.68]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA29623; Tue, 12 Feb 2002 13:00:28 -0800 (PST) Message-Id: <4.3.2.7.2.20020212145917.02b53e10@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Przygienda From: Micah Bartell Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: Les Ginsberg , "'Tony Li'" , Jeff Learman , Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net In-Reply-To: <3C695DF4.39063218@redback.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F7B3@avalon.pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 15:00:22 -0600 If we are going to be kicking out an RFC detailing delta's between the specs and standard implementations, I would think a general RFC covering best practices would be the way to go instead of one off RFCs for each one. /mpb At 10:24 02/12/2002 -0800, Tony Przygienda wrote: >Les Ginsberg wrote: > > > so I applaud Tony's > > call for an RFC which documents this protocol change. Perhaps those who > > chose to ignore the spec would volunteer to write such an RFC?? > >I applaud that, put me on the list of authors pls. who else? ;-) > > thanks > > -- tony > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 16:22:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27753 for ; Tue, 12 Feb 2002 16:22:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CLEQL99880; Tue, 12 Feb 2002 13:14:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CL30L99803 for ; Tue, 12 Feb 2002 13:03:00 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1CL94N18914; Tue, 12 Feb 2002 16:09:04 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAT15612; Tue, 12 Feb 2002 16:08:46 -0500 (EST) Message-Id: <4.3.2.7.2.20020212160602.03bc7360@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Micah Bartell From: Jeff Learman Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: Tony Przygienda , Les Ginsberg , "'Tony Li'" , Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net In-Reply-To: <4.3.2.7.2.20020212145917.02b53e10@cactus.cisco.com> References: <3C695DF4.39063218@redback.com> <17C81AD1F1FED411991E006008F6D1CA01B3F7B3@avalon.pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 16:08:42 -0500 OK, I'll contribute text for the initial ISH thing, & you guys can throw darts at it. Stay tuned. Anyone volunteer to be editor? Anyone have a good list of things to include? I know there has been some discussion but I didn't ever see it get any serious traction. It might be a good idea for people to suggest items to include and we can harangue about that. Regards, Jeff At 04:00 PM 2/12/2002, Micah Bartell wrote: >If we are going to be kicking out an RFC detailing delta's between the specs and standard implementations, I would think a general RFC covering best practices would be the way to go instead of one off RFCs for each one. > >/mpb > >At 10:24 02/12/2002 -0800, Tony Przygienda wrote: >>Les Ginsberg wrote: >> >>> so I applaud Tony's >>> call for an RFC which documents this protocol change. Perhaps those who >>> chose to ignore the spec would volunteer to write such an RFC?? >> >>I applaud that, put me on the list of authors pls. who else? ;-) >> >> thanks >> >> -- tony >> >> >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@external.juniper.net >>http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 16:25:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27934 for ; Tue, 12 Feb 2002 16:25:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CLHSL99912; Tue, 12 Feb 2002 13:17:29 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1CL6XL99838 for ; Tue, 12 Feb 2002 13:06:33 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id 9AB534BA215; Tue, 12 Feb 2002 13:12:28 -0800 (PST) Message-ID: <3C696666.FD926189@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Learman Cc: Micah Bartell , Les Ginsberg , "'Tony Li'" , Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH References: <3C695DF4.39063218@redback.com> <17C81AD1F1FED411991E006008F6D1CA01B3F7B3@avalon.pluris.com> <4.3.2.7.2.20020212160602.03bc7360@dingdong.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 11:00:54 -0800 Content-Transfer-Encoding: 7bit Jeff Learman wrote: > OK, I'll contribute text for the initial ISH thing, & you guys can throw > darts at it. Stay tuned. > > Anyone volunteer to be editor? > > Anyone have a good list of things to include? I know there has been > some discussion but I didn't ever see it get any serious traction. > It might be a good idea for people to suggest items to include and > we can harangue about that. > this discussion has been had on the list and privately, pls read archives, I will not repeat all the arguments again. We strongly encourage RFC per change rather than a 'new 1195' that will contradict 10859 and old 1195 possibly and take forever to finish thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 19:12:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01293 for ; Tue, 12 Feb 2002 19:12:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1D041L00782; Tue, 12 Feb 2002 16:04:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1D03dL00770 for ; Tue, 12 Feb 2002 16:03:39 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from khonsu.sw.nexsi.com ([192.168.103.201]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id QAA15716; Tue, 12 Feb 2002 16:07:21 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <18013552046.20020212160842@nexsi.com> To: Tony Przygienda CC: Jeff Learman , Micah Bartell , Les Ginsberg , "'Tony Li'" , Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH In-Reply-To: <3C696666.FD926189@redback.com> References: <3C695DF4.39063218@redback.com> <17C81AD1F1FED411991E006008F6D1CA01B3F7B3@avalon.pluris.com> <4.3.2.7.2.20020212160602.03bc7360@dingdong.cisco.com> <3C696666.FD926189@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 16:08:42 -0800 Content-Transfer-Encoding: 7bit Tony, > We strongly encourage RFC per change rather than a 'new 1195' that > will contradict 10859 and old 1195 possibly and take forever to finish I think one document spelling out the differences btw 10589 and running code would make much more sense. Whether this should be as part of an update on 1195 (which at least needs the TLV133 fix) or a separate document seems to be an orthogonal issue to me... Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 21:48:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05180 for ; Tue, 12 Feb 2002 21:48:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1D2f0L01403; Tue, 12 Feb 2002 18:41:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1D2e1L01391 for ; Tue, 12 Feb 2002 18:40:01 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.115] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA16618; Tue, 12 Feb 2002 18:44:04 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1322955267.20020212184526@nexsi.com> To: "Amir Hermelin" CC: "ISIS-wg (E-mail)" Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 18:45:26 -0800 Content-Transfer-Encoding: 7bit Amir, If I recall correctly, it was agreed that the "stub" extension does not buy us much, and we should just bite the bullet and do the right thing (i.e., mode 2 in the document ;)... So, I've been trying to convince myself that we really need two modes described in the document and the convincing part is not going well ;)... I keep thinking one solution to the problem is enough and seems that mode 2 provides all we need, so why don't we keep it simple and have just one? Less knobs, less code, less bugs, less headache... I try to argue that mode 1 does not require SPF changes on other systems, but then again it still has the problem of 255 adjacencies max, so it does not solve the issue and eventually people will need mode 2 anyways... So, I guess I'm not convinced... Any ideas? -- Alex Zinin Tuesday, February 12, 2002, 7:10:28 AM, Amir Hermelin wrote: > Hi, > here's a new version of the draft. The main change is the merge between the methods to advertise all types of link-state information in extended LSPs. Therefore Operation Mode 2 changed quite a > bit. The newly proposed TLVs changed from two to one, and its encoding changed as well. Also, some explanation were clarified. > This just about covers all the previous requests from the wg. Please read and post your comments and suggestions. > Thanks. > Abstract > This document describes a mechanism that allows a system to originate > more than 256 LSP fragments, a limit set by the original Intermediate > System to Intermediate System (IS-IS) Routing protocol, as described > in ISO 10589. This mechanism can be used in IP-only, OSI-only, and > dual routers. > -- > Amir Hermelin > Charlotte's Web Networks Inc. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 12 22:47:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07012 for ; Tue, 12 Feb 2002 22:47:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1D3e1L01664; Tue, 12 Feb 2002 19:40:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1D3dlL01644 for ; Tue, 12 Feb 2002 19:39:47 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.115] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id TAA16820; Tue, 12 Feb 2002 19:43:50 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <226541554.20020212194512@nexsi.com> To: "Amir Hermelin" , "ISIS-wg (E-mail)" Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt In-Reply-To: <1322955267.20020212184526@nexsi.com> References: <1322955267.20020212184526@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Feb 2002 19:45:12 -0800 Content-Transfer-Encoding: 7bit Tuesday, February 12, 2002, 6:45:26 PM, Alex Zinin wrote: > I try to argue that mode 1 does not require SPF changes on other > systems, but then again it still has the problem of 255 adjacencies > max, Oops. I didn't mean the number of adjacencies here, of course, but the number of fragments (256) carrying only topological (non-stub) info... I wonder if it would be possible to off-load all reachability info to the extended LSPs, so all fragments of the original LSP would be usable for topological info. Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 05:09:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25271 for ; Wed, 13 Feb 2002 05:09:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DA11L03351; Wed, 13 Feb 2002 02:01:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bart.cwnt.com ([192.116.246.129]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DA0iL03336 for ; Wed, 13 Feb 2002 02:00:44 -0800 (PST) (envelope-from amir@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt Message-ID: Thread-Topic: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt Thread-Index: AcG0OJEpqxkd26VgSDKrGdZRGLcrggAPDu0Q From: "Amir Hermelin" To: "Alex Zinin" Cc: "ISIS-wg (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g1DA0jL03337 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 12:06:37 +0200 Content-Transfer-Encoding: 8bit Alex, thanks for your comments. As I recall from the last meeting, the "agreement" that only mode 2 is needed was only stated by three or four people, and objected by one or two (myself included) - hardly a consensus. Some folks also approached me after the meeting and stated that mode 1 is useful. The important part is this: the draft permits implementation of only mode 2, so mode 1 is optional (as is the whole draft). You don't need extra code, knobs, bugs, etc if your customers don't want this. And since the text is already written, I don't see a good argument for removing it (the text). Of course, whether or not both modes are implemented doesn't affect people who'll want to transition to mode 2 eventually. Does that sound good to you? Any thoughts from the group on this? -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Alex Zinin [mailto:azinin@nexsi.com] > Sent: Wednesday, February 13, 2002 4:45 AM > To: Amir Hermelin > Cc: ISIS-wg (E-mail) > Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt > > > > Amir, > > If I recall correctly, it was agreed that the "stub" extension > does not buy us much, and we should just bite the bullet and > do the right thing (i.e., mode 2 in the document ;)... > > So, I've been trying to convince myself that we really need two > modes described in the document and the convincing part is not > going well ;)... I keep thinking one solution to the problem is > enough and seems that mode 2 provides all we need, so why don't > we keep it simple and have just one? Less knobs, less code, less > bugs, less headache... > > I try to argue that mode 1 does not require SPF changes on other > systems, but then again it still has the problem of 255 adjacencies > max, so it does not solve the issue and eventually people will need > mode 2 anyways... So, I guess I'm not convinced... Any ideas? > > -- > Alex Zinin > > Tuesday, February 12, 2002, 7:10:28 AM, Amir Hermelin wrote: > > > Hi, > > > here's a new version of the draft. The main change is the > merge between the methods to advertise all types of > link-state information in extended LSPs. Therefore Operation > Mode 2 changed quite a > > bit. The newly proposed TLVs changed from two to one, and > its encoding changed as well. Also, some explanation were clarified. > > This just about covers all the previous requests from the > wg. Please read and post your comments and suggestions. > > Thanks. > > > > Abstract > > > This document describes a mechanism that allows a system > to originate > > more than 256 LSP fragments, a limit set by the original > Intermediate > > System to Intermediate System (IS-IS) Routing protocol, > as described > > in ISO 10589. This mechanism can be used in IP-only, > OSI-only, and > > dual routers. > > > > -- > > Amir Hermelin > > Charlotte's Web Networks Inc. > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 05:16:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25529 for ; Wed, 13 Feb 2002 05:16:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DA90L03405; Wed, 13 Feb 2002 02:09:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mailweb22.rediffmail.com ([203.199.83.146]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g1DA8SL03393 for ; Wed, 13 Feb 2002 02:08:30 -0800 (PST) (envelope-from iprouting@rediffmail.com) Received: (qmail 13470 invoked by uid 510); 13 Feb 2002 10:12:54 -0000 Message-ID: <20020213101254.13469.qmail@mailweb22.rediffmail.com> Received: from unknown (198.62.10.2) by rediffmail.com via HTTP; 13 Feb 2002 10:12:54 -0000 MIME-Version: 1.0 From: "Vijay Nath" Reply-To: "Vijay Nath" To: isis-wg@spider.juniper.net Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g1DA8UL03394 Subject: [Isis-wg] (no subject) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 13 Feb 2002 10:12:54 -0000 Content-Transfer-Encoding: 8bit I have a query regarding the Sec. 8.3.3 "RPF on DA Circuits".RPF Cache looks more or like Forwarding Cache at the Control plane. I didn't get the data flow, how data is forwarded at the lower level of ISIS.When RPF Cache is stored in ISIS, how the data is forwarded?. Does IP need to give the packet to ISIS on DA circuits?? V Nath _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 06:51:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28097 for ; Wed, 13 Feb 2002 06:51:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DBh0L04271; Wed, 13 Feb 2002 03:43:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DBgqL04259 for ; Wed, 13 Feb 2002 03:42:52 -0800 (PST) (envelope-from ruwhite@cisco.com) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA13257; Wed, 13 Feb 2002 06:48:48 -0500 (EST) From: Russ White Reply-To: Russ White To: Amir Hermelin cc: Alex Zinin , "ISIS-wg (E-mail)" Subject: RE: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 06:48:48 -0500 (EST) > The important part is this: the draft permits implementation > of only mode 2, so mode 1 is optional (as is the whole > draft). You don't need extra code, knobs, bugs, etc if your > customers don't want this. And since the text is already > written, I don't see a good argument for removing it (the > text). Of course, whether or not both modes are implemented > doesn't affect people who'll want to transition to mode 2 > eventually. I don't really see the usefulness of mode 1--but on the other hand, I don't see any point in taking the text out, now that it's written, since mode 1 is explicitly optional. I don't think many people will actually implement the optional mode 1 unless their customers have code that doesn't support mode 2 in their networks by the time this little mechanism becomes necessary, just through natural attrition. Russ _____________________________ riw@cisco.com <>< Grace Alone _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 07:56:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00063 for ; Wed, 13 Feb 2002 07:56:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DCm0L04577; Wed, 13 Feb 2002 04:48:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DClOL04565 for ; Wed, 13 Feb 2002 04:47:24 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DCrLG27990 for ; Wed, 13 Feb 2002 07:53:21 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DCrJt09410 for ; Wed, 13 Feb 2002 13:53:19 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DCqth15524 for ; Wed, 13 Feb 2002 12:52:56 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS79MZC>; Wed, 13 Feb 2002 12:53:25 -0000 Message-ID: <4103264BC8D3D51180B7002048400C450714F3@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B48D.6A5A0F40" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 12:53:21 -0000 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_01C1B48D.6A5A0F40 Content-Type: text/plain; charset="iso-8859-1" So I have been thinking a little about the wording of a document to describe the situation/history with ISHs and to mandate that an implementation must be able to cope with ISHs or lack of ISHs. I have hit a problem. I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH. Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting? According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:- 1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway. 2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout? The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason. I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects. It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour. What am I missing here? Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs? Sorry for so many questions. Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed. Thoughts? Philip ------_=_NextPart_001_01C1B48D.6A5A0F40 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Question on the usage of ISH and P2PIIH

So I have been thinking a little about the wording of a
document to describe the situation/history with ISHs and to
mandate that an implementation must be able to cope with ISHs
or lack of ISHs.

I have hit a problem.

I assume that there are implementations out there that simply
totally ignore incoming ISHs, and actually do nothing until
they receive an IIH.  Would this be considerred legal or
illegal behaviour in the doc that I am thinking of drafting?

According to 10589 the action on receipt of an ISH is that a
new adjacency is created with adjacencyState "Initialising"
and an IIH PDU is sent. As the IIH would be sent anyway
whenever ISISHelloTimer expires, then there are maybe two
consequences:-

1. The adjacency going to "Initialising", which one could
argue is a non-event, as an adjacency that is "Initialising"
cannot be used for anything, and the state will be ignored
when an IIH finally comes along anyway.

2. Does it mean that the adjacency might come up faster as it
doesn't have to wait for a ISISHelloTimer to timeout?

The only other use for ISH seems to be if a router wants to
act as an OSI End-System for some reason.  I haven't quite
figured out why/when/if an OSI router needs to also have
End-System functionality, unless it is something to do with
OSI redirects.  It would seem to me that if a router needs to
have ES functionality is could attach it to itself rather
than to its neighbour.  What am I missing here?  Why can't
you have an OSI router that is only an IS, and, if so why
does it need to worry about ISHs?

Sorry for so many questions.

Anyhow, we are going to have a choice; either we say that it
is OK to just ignore incoming ISHs, or we say that we must
work if they are not there but if they are then they must be
processed.

Thoughts?

Philip

------_=_NextPart_001_01C1B48D.6A5A0F40-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 08:13:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00467 for ; Wed, 13 Feb 2002 08:12:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DD51L04688; Wed, 13 Feb 2002 05:05:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DD4OL04673 for ; Wed, 13 Feb 2002 05:04:24 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp11.cisco.com [144.254.108.78]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA04833; Wed, 13 Feb 2002 13:10:18 GMT Message-Id: <4.3.2.7.2.20020213130519.0341a3a8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: mike shand Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: <4103264BC8D3D51180B7002048400C450714F3@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 13:09:52 +0000 At 12:53 13/02/2002 +0000, Philip Christian wrote:
The only other use for ISH seems to be if a router wants to
act as an OSI End-System for some reason.  I haven't quite
figured out why/when/if an OSI router needs to also have
End-System functionality, unless it is something to do with
OSI redirects.  It would seem to me that if a router needs to
have ES functionality is could attach it to itself rather
than to its neighbour.  What am I missing here?  Why can't
you have an OSI router that is only an IS, and, if so why
does it need to worry about ISHs?

Its not that the router is acting as an ES (if it DID want to do something strange like that it should be sending ESHs, but PLEASE not both ISHs and ESHs).

The issue is that the router has an adjacent ES (over the pt-pt link). The ES wants to see an ISH to know that it has a router adjacent to it). It's no good just sending IIHs, since the ES just plain doesn't understand them.

However, as has been pointed out before, this a fairly rare scenario, and getting rarer by the minute.

Mike



_______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 08:17:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00537 for ; Wed, 13 Feb 2002 08:17:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DDA1L04746; Wed, 13 Feb 2002 05:10:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DD9XL04731 for ; Wed, 13 Feb 2002 05:09:33 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DDFNG17034; Wed, 13 Feb 2002 08:15:23 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DDFKt25166; Wed, 13 Feb 2002 14:15:20 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DDEuh01349; Wed, 13 Feb 2002 13:14:57 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS793JZ>; Wed, 13 Feb 2002 13:15:26 -0000 Message-ID: <4103264BC8D3D51180B7002048400C450714F4@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B490.7E689D00" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 13:15:23 -0000 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_01C1B490.7E689D00 Content-Type: text/plain; charset="iso-8859-1" So that explains why an OSI router needs to send ISH, as there might be an ES that needs it. It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard? Philip -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: 13 February 2002 13:10 To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH At 12:53 13/02/2002 +0000, Philip Christian wrote: The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason. I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects. It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour. What am I missing here? Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs? Its not that the router is acting as an ES (if it DID want to do something strange like that it should be sending ESHs, but PLEASE not both ISHs and ESHs). The issue is that the router has an adjacent ES (over the pt-pt link). The ES wants to see an ISH to know that it has a router adjacent to it). It's no good just sending IIHs, since the ES just plain doesn't understand them. However, as has been pointed out before, this a fairly rare scenario, and getting rarer by the minute. Mike ------_=_NextPart_001_01C1B490.7E689D00 Content-Type: text/html; charset="iso-8859-1"
So that explains why an OSI router needs to send ISH, as there might be an ES that needs it.
It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard?
 
Philip
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: 13 February 2002 13:10
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

At 12:53 13/02/2002 +0000, Philip Christian wrote:
The only other use for ISH seems to be if a router wants to
act as an OSI End-System for some reason.  I haven't quite
figured out why/when/if an OSI router needs to also have
End-System functionality, unless it is something to do with
OSI redirects.  It would seem to me that if a router needs to
have ES functionality is could attach it to itself rather
than to its neighbour.  What am I missing here?  Why can't
you have an OSI router that is only an IS, and, if so why
does it need to worry about ISHs?

Its not that the router is acting as an ES (if it DID want to do something strange like that it should be sending ESHs, but PLEASE not both ISHs and ESHs).

The issue is that the router has an adjacent ES (over the pt-pt link). The ES wants to see an ISH to know that it has a router adjacent to it). It's no good just sending IIHs, since the ES just plain doesn't understand them.

However, as has been pointed out before, this a fairly rare scenario, and getting rarer by the minute.

Mike



------_=_NextPart_001_01C1B490.7E689D00-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 08:24:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00768 for ; Wed, 13 Feb 2002 08:24:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DDH1L04816; Wed, 13 Feb 2002 05:17:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DDGqL04804 for ; Wed, 13 Feb 2002 05:16:52 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp11.cisco.com [144.254.108.78]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA05343; Wed, 13 Feb 2002 13:22:47 GMT Message-Id: <4.3.2.7.2.20020213132037.03452cc0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: mike shand Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: <4103264BC8D3D51180B7002048400C450714F4@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 13:22:20 +0000 At 13:15 13/02/2002 +0000, Philip Christian wrote:
So that explains why an OSI router needs to send ISH, as there might be an ES that needs it.
It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard?

Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH).

But that really doesn't apply any more, even if it ever did.

        Mike


_______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 10:08:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06137 for ; Wed, 13 Feb 2002 10:08:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DF02L05296; Wed, 13 Feb 2002 07:00:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DExML05278 for ; Wed, 13 Feb 2002 06:59:22 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DF5Cg00005; Wed, 13 Feb 2002 10:05:13 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DF5At17391; Wed, 13 Feb 2002 16:05:10 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DF4jh23800; Wed, 13 Feb 2002 15:04:45 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS79XCB>; Wed, 13 Feb 2002 15:05:06 -0000 Message-ID: <4103264BC8D3D51180B7002048400C450714F9@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B49F.D6371B60" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 15:05:12 -0000 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_01C1B49F.D6371B60 Content-Type: text/plain; charset="iso-8859-1" From ISO/IEC 10589:1992 8.2.3 "8.2.3 Sending point-to-point IIH PDUs An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the circuit is first enabled; or b) whenever iSISHelloTimer expires" In ISO/IEC 10589:2001 8.2.4 this becomes "8.2.4 Sending point-to-point IIH PDUs An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the IS receives an ISH PDU b) whenever iSISHelloTimer expires" So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System. One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end. At least that is my enterpretation of it. I'd love to know the reasoning behind the change. Philip -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: 13 February 2002 13:22 To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH At 13:15 13/02/2002 +0000, Philip Christian wrote: So that explains why an OSI router needs to send ISH, as there might be an ES that needs it. It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard? Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH). But that really doesn't apply any more, even if it ever did. Mike ------_=_NextPart_001_01C1B49F.D6371B60 Content-Type: text/html; charset="iso-8859-1"
From ISO/IEC 10589:1992 8.2.3
"8.2.3 Sending point-to-point IIH PDUs
An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the circuit is first enabled; or
b) whenever iSISHelloTimer expires"
 
In ISO/IEC 10589:2001 8.2.4 this becomes
"8.2.4 Sending point-to-point IIH PDUs
An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the IS receives an ISH PDU
b) whenever iSISHelloTimer expires"
 
So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System.
 
One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end.
 
At least that is my enterpretation of it.
 
I'd love to know the reasoning behind the change.
 
Philip
 
 
 
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

At 13:15 13/02/2002 +0000, Philip Christian wrote:
So that explains why an OSI router needs to send ISH, as there might be an ES that needs it.
It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard?

Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH).

But that really doesn't apply any more, even if it ever did.

        Mike


------_=_NextPart_001_01C1B49F.D6371B60-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 10:27:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07433 for ; Wed, 13 Feb 2002 10:27:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DFK1L05434; Wed, 13 Feb 2002 07:20:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DFJJL05417 for ; Wed, 13 Feb 2002 07:19:19 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp11.cisco.com [144.254.108.78]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA10968; Wed, 13 Feb 2002 15:25:14 GMT Message-Id: <4.3.2.7.2.20020213151511.033d28a0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: mike shand Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: <4103264BC8D3D51180B7002048400C450714F9@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 15:24:41 +0000 At 15:05 13/02/2002 +0000, Philip Christian wrote:
I'd love to know the reasoning behind the change.

My guess is that there wasn't any reasoning at all, but that it happened as an accident, when the full description of the use of ISHs was removed and replaced by the second para in 8.2 which says

The IS shall operate the ISO  9542 protocol, shall be able to receive ISO 9542 ISH PDUs from other ISs and shall store the information so obtained in the adjacency database.

Probably the intention was that this included the sending of the initial ISH, but the words at the beginning of 8.2.3 were fumbled so that it got contradicted.

Note that there is a vestige of the original behaviour in bulllet (c) of that para which says

The first pt-pt ISH PDU (i.e. that transmitted as a result of receiving an ISH PDU,....)

However, I guess it says what it says, and we have to cut our cloth accordingly.

        Mike


historical note:- the words at the start of 8.2 were inserted when the original DECnet spec was ISO'ised. It used to say

When a pt-pt router to router hello is required to be transmitted as described in previous sections, it is constructed as follows...

and then proceeds with

a) the circuit type field shall be set... etc.

and of course the "previous sections" described sending an IIH only after receiving an ISH.

But this is all history now.


:-)



_______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 10:51:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08435 for ; Wed, 13 Feb 2002 10:51:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DFh1L05554; Wed, 13 Feb 2002 07:43:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DFfuL05539 for ; Wed, 13 Feb 2002 07:41:56 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1DFmCE22657; Wed, 13 Feb 2002 10:48:12 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAT32547; Wed, 13 Feb 2002 10:47:55 -0500 (EST) Message-Id: <4.3.2.7.2.20020213104724.03bed310@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: Jeff Learman Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5935364==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 10:47:46 -0500 --=====================_5935364==_.ALT Content-Type: text/plain; charset="us-ascii" At 07:43 AM 2/13/2002, Philip Christian wrote: >So I have been thinking a little about the wording of a document to describe the situation/history with ISHs and to mandate that an implementation must be able to cope with ISHs or lack of ISHs. > >I have hit a problem. > >I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH. Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting? First of all, I think it would be best to create an informational RFC, alerting implementors to common practice. That way, we avoid legal vs. illegal, and simply describe behavior that an implementation is recommended to be able to interoperate with. In this way, we can point out different interpretations of the spec, which is helpful to implementors without creating a new spec and new contradictions. Whether an informational RFC should contain a number of items or whether there should be one per issue I leave to the others to hash out -- evidently it's been hashed out a bit already. I can see pros and cons on both sides of that issue. >According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:- > >1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway. I agree, and therefore don't think it's necessary to specify anything. We should focus on observable behavior, not internal models. It's hard to write a good spec without an internal model, so I'm not criticizing 10589 here. But in this case, we don't need to exacerbate the problems caused by specifying an internal model, we can just talk about behavior. The hard work has already been done. >2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout? I assume that implementations that don't send ISH PDUs also don't wait for a timer to expire, they just send the IIH when the circuit comes up, so the adjacency would come up right away in either case. Note that 10589:1992 says to send the IIH when the circuit is first enabled; only 10589:1992+TC1:1993 says to wait to receive an ISH. Some implementations don't follow TC1, which clearly says when to send the ISH. Prior to that, there's only the implication that you wait to send an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1). >The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason. I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects. It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour. What am I missing here? Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs? The only real purpose of the ISH is in case the system at the other end supports CLNP but is not running IS-IS, such as when it's an ES. Assuming the OSI router's NSAP matches its NET (except for NSEL), then its network service users are reachable without doing anything special. Admittedly, according to rule changes in TC1:1993, the ISH also serves the purpose of starting the process to bring up the adjacency. But this is unnecessary. The only information in the ISH that is pertinent is "I'm a router!" By the way, the ISH is neither necessary nor sufficient for handling network service users on the OSI router, which is very important but was ignored in a lot of the early OSI standards. There are two cases: (a) all NSAPs for the network service user matches the NET (except for NSEL), and (b) there are NSAPs that don't match the NET. Case (a) is naturally handled by IS-IS, and the ISH isn't needed. Case (b) isn't covered in IS-IS, and you can't use ISH PDUs to solve it -- because the ISH can only contain one NET, and it has to match the adjacency so you can't just send a bunch of them. This was resolved for SONET NEs by the SIF; the router should advertise these as ES neighbors with path costs of 1. (I argued for zero, but that didn't go over because it might have caused trouble with implementations that couldn't handle zero metrics anywhere outside pseudonode LSPs.) Hopefully we don't need to go into that in an RFC! >Sorry for so many questions. Sorry for such long answers ;-) >Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed. I think the thing to do is to state that prevalent implementations do not send ISHs on PTP links, and that an implementation is advised to bring up the adjacency anyway. To do this, we must relax the rule in 10589:1992+TC1:1993 that does not permit sending an IIH until an ISH has been received, and allow sending of the IIH when an IIH has been received, or for systems where connections to OSI end systems over PTP links are not supported, the IIH can be sent as soon as the link is up. I also think it may be appropriate to include a little history here, showing how 19589:1992 could reasonably be interpreted to allow sending IIHs before receiving ISHs, yet the rule in TC1 would not interoperate with this interpretation. (I think that TC1, while well-intentioned, was unfortunately misworded. It should have allowed sending an IIH after receiving one.) Regards, Jeff >Thoughts? > >Philip --=====================_5935364==_.ALT Content-Type: text/html; charset="us-ascii" At 07:43 AM 2/13/2002, Philip Christian wrote:

So I have been thinking a little about the wording of a document to describe the situation/history with ISHs and to mandate that an implementation must be able to cope with ISHs or lack of ISHs.

I have hit a problem.

I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH.  Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting?

First of all, I think it would be best to create an informational
RFC, alerting implementors to common practice.  That way, we avoid
legal vs. illegal, and simply describe behavior that an implementation
is recommended to be able to interoperate with.  In this way, we can
point out different interpretations of the spec, which is helpful
to implementors without creating a new spec and new contradictions.

Whether an informational RFC should contain a number of items or
whether there should be one per issue I leave to the others to hash
out -- evidently it's been hashed out a bit already.  I can see
pros and cons on both sides of that issue.

According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:-

1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway.

I agree, and therefore don't think it's necessary to specify anything.
We should focus on observable behavior, not internal models.  It's hard
to write a good spec without an internal model, so I'm not criticizing
10589 here.  But in this case, we don't need to exacerbate the problems
caused by specifying an internal model, we can just talk about behavior.
The hard work has already been done.

2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout?

I assume that implementations that don't send ISH PDUs also don't wait
for a timer to expire, they just send the IIH when the circuit comes up,
so the adjacency would come up right away in either case.  Note that
10589:1992 says to send the IIH when the circuit is first enabled;
only 10589:1992+TC1:1993 says to wait to receive an ISH.  Some
implementations don't follow TC1, which clearly says when to send the
ISH.  Prior to that, there's only the implication that you wait to send
an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1).

The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason.  I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects.  It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour.  What am I missing here?  Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs?

The only real purpose of the ISH is in case the system at the other end
supports CLNP but is not running IS-IS, such as when it's an ES.  Assuming
the OSI router's NSAP matches its NET (except for NSEL), then its network
service users are reachable without doing anything special.  Admittedly,
according to rule changes in TC1:1993, the ISH also serves the purpose of
starting the process to bring up the adjacency.  But this is unnecessary.
The only information in the ISH that is pertinent is "I'm a router!"

By the way, the ISH is neither necessary nor sufficient for handling
network service users on the OSI router, which is very important but
was ignored in a lot of the early OSI standards.  There are two cases:
(a) all NSAPs for the network service user matches the NET (except for
NSEL), and (b) there are NSAPs that don't match the NET.  Case (a) is
naturally handled by IS-IS, and the ISH isn't needed.  Case (b) isn't
covered in IS-IS, and you can't use ISH PDUs to solve it -- because
the ISH can only contain one NET, and it has to match the adjacency
so you can't just send a bunch of them.  This was resolved for SONET
NEs by the SIF; the router should advertise these as ES neighbors with
path costs of 1.  (I argued for zero, but that didn't go over because it
might have caused trouble with implementations that couldn't handle
zero metrics anywhere outside pseudonode LSPs.)  Hopefully we don't need
to go into that in an RFC!

Sorry for so many questions.

Sorry for such long answers ;-)


Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed.

I think the thing to do is to state that prevalent implementations
do not send ISHs on PTP links, and that an implementation is advised to
bring up the adjacency anyway.  To do this, we must relax the rule in 10589:1992+TC1:1993 that does not permit sending an IIH until an ISH
has been received, and allow sending of the IIH when an IIH has been
received, or for systems where connections to OSI end systems over
PTP links are not supported, the IIH can be sent as soon as the link
is up.

I also think it may be appropriate to include a little history here,
showing how 19589:1992 could reasonably be interpreted to allow
sending IIHs before receiving ISHs, yet the rule in TC1 would not
interoperate with this interpretation.  (I think that TC1, while
well-intentioned, was unfortunately misworded.  It should have
allowed sending an IIH after receiving one.)

Regards,
Jeff

Thoughts?

Philip
--=====================_5935364==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 10:58:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08643 for ; Wed, 13 Feb 2002 10:58:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DFp1L05645; Wed, 13 Feb 2002 07:51:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DFo7L05628 for ; Wed, 13 Feb 2002 07:50:07 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DFu5Z17937 for ; Wed, 13 Feb 2002 10:56:05 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DFu2t29228 for ; Wed, 13 Feb 2002 16:56:03 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DFtch05767 for ; Wed, 13 Feb 2002 15:55:38 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS796FW>; Wed, 13 Feb 2002 15:55:59 -0000 Message-ID: <4103264BC8D3D51180B7002048400C450714FB@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4A6.EA14D850" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 15:55:52 -0000 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_01C1B4A6.EA14D850 Content-Type: text/plain; charset="iso-8859-1" Yes of course. The conclusion is then:- 1. If you don't send ISHs, then it makes sense to send IIH instead as soon as a circuit is enabled, as per 10589:1992. 2. If you don't process incoming ISHs, and, if the other end sends only ISH upon circuit enable, then you might have to wait one iSISHelloTimer interval before you see him. 3. If you follow 10589:1992+TC1 or 10589:2001 and only send ISH upon circuit enable, then the you might have to wait for one iSISHelloTimer before he sees you, but, if you follow 10589:1992 and send IIH upon circuit enable then the other end is guaranteed to see you straight away. These are simple facts that can be stated, along with the fact that there are implementations out there which do not send ISHs. I guess that I can start typing the draft now. Philip -----Original Message----- From: Jeff Learman [mailto:jlearman@cisco.com] Sent: 13 February 2002 15:14 To: Christian, Philip [HAL02:GI50:EXCH] Cc: Tony Przygienda; Micah Bartell; Les Ginsberg; 'Tony Li'; Ken Larmer; Shankar Vemulapalli; Chan, Chung Ming; isis-wg@spider.juniper.net; 'Alex Zinin' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH At 07:43 AM 2/13/2002, Philip Christian wrote: So I have been thinking a little about the wording of a document to describe the situation/history with ISHs and to mandate that an implementation must be able to cope with ISHs or lack of ISHs. I have hit a problem. I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH. Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting? First of all, I think it would be best to create an informational RFC, alerting implementors to common practice. That way, we avoid legal vs. illegal, and simply describe behavior that an implementation is recommended to be able to interoperate with. In this way, we can point out different interpretations of the spec, which is helpful to implementors without creating a new spec and new contradictions. Whether an informational RFC should contain a number of items or whether there should be one per issue I leave to the others to hash out -- evidently it's been hashed out a bit already. I can see pros and cons on both sides of that issue. According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:- 1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway. I agree, and therefore don't think it's necessary to specify anything. We should focus on observable behavior, not internal models. It's hard to write a good spec without an internal model, so I'm not criticizing 10589 here. But in this case, we don't need to exacerbate the problems caused by specifying an internal model, we can just talk about behavior. The hard work has already been done. 2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout? I assume that implementations that don't send ISH PDUs also don't wait for a timer to expire, they just send the IIH when the circuit comes up, so the adjacency would come up right away in either case. Note that 10589:1992 says to send the IIH when the circuit is first enabled; only 10589:1992+TC1:1993 says to wait to receive an ISH. Some implementations don't follow TC1, which clearly says when to send the ISH. Prior to that, there's only the implication that you wait to send an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1). The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason. I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects. It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour. What am I missing here? Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs? The only real purpose of the ISH is in case the system at the other end supports CLNP but is not running IS-IS, such as when it's an ES. Assuming the OSI router's NSAP matches its NET (except for NSEL), then its network service users are reachable without doing anything special. Admittedly, according to rule changes in TC1:1993, the ISH also serves the purpose of starting the process to bring up the adjacency. But this is unnecessary. The only information in the ISH that is pertinent is "I'm a router!" By the way, the ISH is neither necessary nor sufficient for handling network service users on the OSI router, which is very important but was ignored in a lot of the early OSI standards. There are two cases: (a) all NSAPs for the network service user matches the NET (except for NSEL), and (b) there are NSAPs that don't match the NET. Case (a) is naturally handled by IS-IS, and the ISH isn't needed. Case (b) isn't covered in IS-IS, and you can't use ISH PDUs to solve it -- because the ISH can only contain one NET, and it has to match the adjacency so you can't just send a bunch of them. This was resolved for SONET NEs by the SIF; the router should advertise these as ES neighbors with path costs of 1. (I argued for zero, but that didn't go over because it might have caused trouble with implementations that couldn't handle zero metrics anywhere outside pseudonode LSPs.) Hopefully we don't need to go into that in an RFC! Sorry for so many questions. Sorry for such long answers ;-) Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed. I think the thing to do is to state that prevalent implementations do not send ISHs on PTP links, and that an implementation is advised to bring up the adjacency anyway. To do this, we must relax the rule in 10589:1992+TC1:1993 that does not permit sending an IIH until an ISH has been received, and allow sending of the IIH when an IIH has been received, or for systems where connections to OSI end systems over PTP links are not supported, the IIH can be sent as soon as the link is up. I also think it may be appropriate to include a little history here, showing how 19589:1992 could reasonably be interpreted to allow sending IIHs before receiving ISHs, yet the rule in TC1 would not interoperate with this interpretation. (I think that TC1, while well-intentioned, was unfortunately misworded. It should have allowed sending an IIH after receiving one.) Regards, Jeff Thoughts? Philip ------_=_NextPart_001_01C1B4A6.EA14D850 Content-Type: text/html; charset="iso-8859-1"
Yes of course. The conclusion is then:-
 
1. If you don't send ISHs, then it makes sense to send IIH instead as soon as a circuit is enabled, as per 10589:1992.
 
2. If you don't process incoming ISHs, and, if the other end sends only ISH upon circuit enable, then you might have to wait one iSISHelloTimer interval before you see him.
 
3. If you follow 10589:1992+TC1 or 10589:2001 and only send ISH upon circuit enable, then the you might have to wait for one iSISHelloTimer before he sees you, but, if you follow 10589:1992 and send IIH upon circuit enable then the other end is guaranteed to see you straight away.
 
These are simple facts that can be stated, along with the fact that there are implementations out there which do not send ISHs.
 
I guess that I can start typing the draft now.
 
Philip
-----Original Message-----
From: Jeff Learman [mailto:jlearman@cisco.com]
Sent: 13 February 2002 15:14
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: Tony Przygienda; Micah Bartell; Les Ginsberg; 'Tony Li'; Ken Larmer; Shankar Vemulapalli; Chan, Chung Ming; isis-wg@spider.juniper.net; 'Alex Zinin'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

At 07:43 AM 2/13/2002, Philip Christian wrote:

So I have been thinking a little about the wording of a document to describe the situation/history with ISHs and to mandate that an implementation must be able to cope with ISHs or lack of ISHs.

I have hit a problem.

I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH.  Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting?

First of all, I think it would be best to create an informational
RFC, alerting implementors to common practice.  That way, we avoid
legal vs. illegal, and simply describe behavior that an implementation
is recommended to be able to interoperate with.  In this way, we can
point out different interpretations of the spec, which is helpful
to implementors without creating a new spec and new contradictions.

Whether an informational RFC should contain a number of items or
whether there should be one per issue I leave to the others to hash
out -- evidently it's been hashed out a bit already.  I can see
pros and cons on both sides of that issue.

According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:-

1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway.

I agree, and therefore don't think it's necessary to specify anything.
We should focus on observable behavior, not internal models.  It's hard
to write a good spec without an internal model, so I'm not criticizing
10589 here.  But in this case, we don't need to exacerbate the problems
caused by specifying an internal model, we can just talk about behavior.
The hard work has already been done.

2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout?

I assume that implementations that don't send ISH PDUs also don't wait
for a timer to expire, they just send the IIH when the circuit comes up,
so the adjacency would come up right away in either case.  Note that
10589:1992 says to send the IIH when the circuit is first enabled;
only 10589:1992+TC1:1993 says to wait to receive an ISH.  Some
implementations don't follow TC1, which clearly says when to send the
ISH.  Prior to that, there's only the implication that you wait to send
an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1).

The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason.  I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects.  It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour.  What am I missing here?  Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs?

The only real purpose of the ISH is in case the system at the other end
supports CLNP but is not running IS-IS, such as when it's an ES.  Assuming
the OSI router's NSAP matches its NET (except for NSEL), then its network
service users are reachable without doing anything special.  Admittedly,
according to rule changes in TC1:1993, the ISH also serves the purpose of
starting the process to bring up the adjacency.  But this is unnecessary.
The only information in the ISH that is pertinent is "I'm a router!"

By the way, the ISH is neither necessary nor sufficient for handling
network service users on the OSI router, which is very important but
was ignored in a lot of the early OSI standards.  There are two cases:
(a) all NSAPs for the network service user matches the NET (except for
NSEL), and (b) there are NSAPs that don't match the NET.  Case (a) is
naturally handled by IS-IS, and the ISH isn't needed.  Case (b) isn't
covered in IS-IS, and you can't use ISH PDUs to solve it -- because
the ISH can only contain one NET, and it has to match the adjacency
so you can't just send a bunch of them.  This was resolved for SONET
NEs by the SIF; the router should advertise these as ES neighbors with
path costs of 1.  (I argued for zero, but that didn't go over because it
might have caused trouble with implementations that couldn't handle
zero metrics anywhere outside pseudonode LSPs.)  Hopefully we don't need
to go into that in an RFC!

Sorry for so many questions.

Sorry for such long answers ;-)


Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed.

I think the thing to do is to state that prevalent implementations
do not send ISHs on PTP links, and that an implementation is advised to
bring up the adjacency anyway.  To do this, we must relax the rule in 10589:1992+TC1:1993 that does not permit sending an IIH until an ISH
has been received, and allow sending of the IIH when an IIH has been
received, or for systems where connections to OSI end systems over
PTP links are not supported, the IIH can be sent as soon as the link
is up.

I also think it may be appropriate to include a little history here,
showing how 19589:1992 could reasonably be interpreted to allow
sending IIHs before receiving ISHs, yet the rule in TC1 would not
interoperate with this interpretation.  (I think that TC1, while
well-intentioned, was unfortunately misworded.  It should have
allowed sending an IIH after receiving one.)

Regards,
Jeff

Thoughts?

Philip
------_=_NextPart_001_01C1B4A6.EA14D850-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 12:37:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14931 for ; Wed, 13 Feb 2002 12:37:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DHT1L06104; Wed, 13 Feb 2002 09:29:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.227.69]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DHSaL06092 for ; Wed, 13 Feb 2002 09:28:36 -0800 (PST) (envelope-from svemulap@cisco.com) Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.102.160]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA00199 for ; Wed, 13 Feb 2002 09:34:37 -0800 (PST) From: Shankar Vemulapalli To: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 09:34:13 -0800 (PST) Sorry for any duplicate e-mail if you receive any. Got an e-mail from isis-wg-admin saying it has too many recipients - Sending it again if you haven't received one. Thanks, /Shankar ---------- Forwarded message ---------- Date: Wed, 13 Feb 2002 09:19:55 -0800 (PST) From: Shankar Vemulapalli To: Micah Bartell Cc: Philip Christian , 'Jeff Learman' , Tony Przygienda , Les Ginsberg , 'Tony Li' , Ken Larmer , "Chan, Chung Ming" , isis-wg@spider.juniper.net, 'Alex Zinin' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Hi Michah - It is looking good with a good start. Couple of points/notes: In the "Introduction" section, I would probably add some more [general] description that in existing production neteworks the number of ES are very less and that this is even more true on the p2p interfaces [in those lines]. Also, it would be good to add saying that the vendors can have knob to turn on or off this ISH packets on the p2p interfaces. Any adv or dis-adv on the routers CPU or any other one by just sending IIH vs IIH + ISH - [a thought + whether to address this issue] Thanks, /Shankar At 10:35am 02/13/02 -0600, Micah Bartell wrote: > Alright, I have no idea who is working on a draft at this point. Feel free > to hack off of this one, which was just a bit of scribbling late last night. > > /mpb > > > IS-IS Adjacency Establishment in IP Only Environments > > > > 1. Status of this Document > > This document is an Internet-Draft and is in full conformance with all > provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. Note that other groups > may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsolete by other documents at any > time. It is inappropriate to use Internet-Drafts as reference material > or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > 2. Abstract > > This document describes a modification to the IS-IS protocol in IP Only > environments for adjacency establishment over Point to Point circuits. > The IS-IS protocol is specified in [2], with extensions for supporting > IPv4 specified in [1]. > > This draft describes a modification to the IS-IS protocol, which will > allow an IS-IS adjacency to be established over Point to Point circuits > without the use of an Intermediate System Hello PDU (ISH). > > 3. Introduction > > The IS-IS protocol as defined in [1] was intended for use with the > Connectionless Network Service (CLNS). An Intermediate System would > announce it's existance through the issuance of an ISH PDU, to allow > End Systems (ES) to form an ES-IS adjacency providing connectivity. > Typically an ES would exist on an broadcast subnetwork. It is possible > for an ES to connect to an IS via a Point to Point circuit, creating > the requirement for an ISH PDU to be first issued over a Point to > Point circuit. An IS on the Point to Point circuit would issue an > Intermediate System to Intermediate System Hello PDU (IIH) in response > to the ISH PDU. > > In an IP Only environment, there is no need to issue an ISH PDU over a > Point to Point subnetwork because there are no End Systems with which to > form an ES-IS adjacency. [2] requires that an ISH be received in order > to issue an IIH PDU. > > 4. Best Common Practice > > An IP Only implemenation has no need to issue an ISH PDU as described in > section 8.2.4 of [2]. An IP Only implementation MAY issue an IIH PDU > when a Point to Point circuit transitions into an "Up" state to > initiate the formation of an IS-IS adjacency. The IIH PDU SHOULD still > be issued in conformance with section 8.2.4 of [2] with the exception > of the requirement for reception of an ISH PDU. > > An implementation that supports the forwarding of CLNS PDU's MUST act in > full accordance with section 8.2.4 of [2] when CLNS functionality is > enabled, including the initial issuance of an ISH PDU. > > 5. Security Considerations > > This document raises no new security issues for IS-IS. > > 6. References > > [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual > Environments" RFC 1195, December 1990 > > [2] ISO, "Intermediate System to Intermediate System Intra- > Domain Routeing Exchange Protocol for use in Conjunction with the > Protocol for Providing the Connectionless-mode Network Service (ISO > 8473)", ISO/IEC 10589:1992 > > At 15:51 02/13/2002 +0000, Philip Christian wrote: > >Yes of course. The conclusion is then:- > > > >1. If you don't send ISHs, then it makes sense to send IIH instead as soon > >as a circuit is enabled, as per 10589:1992. > > > >2. If you don't process incoming ISHs, and, if the other end sends only > >ISH upon circuit enable, then you might have to wait one iSISHelloTimer > >interval before you see him. > > > >3. If you follow 10589:1992+TC1 or 10589:2001 and only send ISH upon > >circuit enable, then the you might have to wait for one iSISHelloTimer > >before he sees you, but, if you follow 10589:1992 and send IIH upon > >circuit enable then the other end is guaranteed to see you straight away. > > > >These are simple facts that can be stated, along with the fact that there > >are implementations out there which do not send ISHs. > > > >I guess that I can start typing the draft now. > > > >Philip > >>-----Original Message----- > >>From: Jeff Learman [mailto:jlearman@cisco.com] > >>Sent: 13 February 2002 15:14 > >>To: Christian, Philip [HAL02:GI50:EXCH] > >>Cc: Tony Przygienda; Micah Bartell; Les Ginsberg; 'Tony Li'; Ken Larmer; > >>Shankar Vemulapalli; Chan, Chung Ming; isis-wg@spider.juniper.net; 'Alex Zinin' > >>Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH > >> > >>At 07:43 AM 2/13/2002, Philip Christian wrote: > >> > >>>So I have been thinking a little about the wording of a document to > >>>describe the situation/history with ISHs and to mandate that an > >>>implementation must be able to cope with ISHs or lack of ISHs. > >>> > >>>I have hit a problem. > >>> > >>>I assume that there are implementations out there that simply totally > >>>ignore incoming ISHs, and actually do nothing until they receive an > >>>IIH. Would this be considerred legal or illegal behaviour in the doc > >>>that I am thinking of drafting? > >> > >>First of all, I think it would be best to create an informational > >>RFC, alerting implementors to common practice. That way, we avoid > >>legal vs. illegal, and simply describe behavior that an implementation > >>is recommended to be able to interoperate with. In this way, we can > >>point out different interpretations of the spec, which is helpful > >>to implementors without creating a new spec and new contradictions. > >> > >>Whether an informational RFC should contain a number of items or > >>whether there should be one per issue I leave to the others to hash > >>out -- evidently it's been hashed out a bit already. I can see > >>pros and cons on both sides of that issue. > >> > >>>According to 10589 the action on receipt of an ISH is that a new > >>>adjacency is created with adjacencyState "Initialising" and an IIH PDU > >>>is sent. As the IIH would be sent anyway whenever ISISHelloTimer > >>>expires, then there are maybe two consequences:- > >>> > >>>1. The adjacency going to "Initialising", which one could argue is a > >>>non-event, as an adjacency that is "Initialising" cannot be used for > >>>anything, and the state will be ignored when an IIH finally comes along anyway. > >> > >>I agree, and therefore don't think it's necessary to specify anything. > >>We should focus on observable behavior, not internal models. It's hard > >>to write a good spec without an internal model, so I'm not criticizing > >>10589 here. But in this case, we don't need to exacerbate the problems > >>caused by specifying an internal model, we can just talk about behavior. > >>The hard work has already been done. > >> > >>>2. Does it mean that the adjacency might come up faster as it doesn't > >>>have to wait for a ISISHelloTimer to timeout? > >> > >>I assume that implementations that don't send ISH PDUs also don't wait > >>for a timer to expire, they just send the IIH when the circuit comes up, > >>so the adjacency would come up right away in either case. Note that > >>10589:1992 says to send the IIH when the circuit is first enabled; > >>only 10589:1992+TC1:1993 says to wait to receive an ISH. Some > >>implementations don't follow TC1, which clearly says when to send the > >>ISH. Prior to that, there's only the implication that you wait to send > >>an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1). > >> > >>>The only other use for ISH seems to be if a router wants to act as an > >>>OSI End-System for some reason. I haven't quite figured out why/when/if > >>>an OSI router needs to also have End-System functionality, unless it is > >>>something to do with OSI redirects. It would seem to me that if a > >>>router needs to have ES functionality is could attach it to itself > >>>rather than to its neighbour. What am I missing here? Why can't you > >>>have an OSI router that is only an IS, and, if so why does it need to > >>>worry about ISHs? > >> > >>The only real purpose of the ISH is in case the system at the other end > >>supports CLNP but is not running IS-IS, such as when it's an ES. Assuming > >>the OSI router's NSAP matches its NET (except for NSEL), then its network > >>service users are reachable without doing anything special. Admittedly, > >>according to rule changes in TC1:1993, the ISH also serves the purpose of > >>starting the process to bring up the adjacency. But this is unnecessary. > >>The only information in the ISH that is pertinent is "I'm a router!" > >> > >>By the way, the ISH is neither necessary nor sufficient for handling > >>network service users on the OSI router, which is very important but > >>was ignored in a lot of the early OSI standards. There are two cases: > >>(a) all NSAPs for the network service user matches the NET (except for > >>NSEL), and (b) there are NSAPs that don't match the NET. Case (a) is > >>naturally handled by IS-IS, and the ISH isn't needed. Case (b) isn't > >>covered in IS-IS, and you can't use ISH PDUs to solve it -- because > >>the ISH can only contain one NET, and it has to match the adjacency > >>so you can't just send a bunch of them. This was resolved for SONET > >>NEs by the SIF; the router should advertise these as ES neighbors with > >>path costs of 1. (I argued for zero, but that didn't go over because it > >>might have caused trouble with implementations that couldn't handle > >>zero metrics anywhere outside pseudonode LSPs.) Hopefully we don't need > >>to go into that in an RFC! > >> > >>>Sorry for so many questions. > >> > >>Sorry for such long answers ;-) > >> > >> > >>>Anyhow, we are going to have a choice; either we say that it is OK to > >>>just ignore incoming ISHs, or we say that we must work if they are not > >>>there but if they are then they must be processed. > >> > >>I think the thing to do is to state that prevalent implementations > >>do not send ISHs on PTP links, and that an implementation is advised to > >>bring up the adjacency anyway. To do this, we must relax the rule in > >>10589:1992+TC1:1993 that does not permit sending an IIH until an ISH > >>has been received, and allow sending of the IIH when an IIH has been > >>received, or for systems where connections to OSI end systems over > >>PTP links are not supported, the IIH can be sent as soon as the link > >>is up. > >> > >>I also think it may be appropriate to include a little history here, > >>showing how 19589:1992 could reasonably be interpreted to allow > >>sending IIHs before receiving ISHs, yet the rule in TC1 would not > >>interoperate with this interpretation. (I think that TC1, while > >>well-intentioned, was unfortunately misworded. It should have > >>allowed sending an IIH after receiving one.) > >> > >>Regards, > >>Jeff > >> > >>>Thoughts? > >>> > >>>Philip > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 13:28:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16323 for ; Wed, 13 Feb 2002 13:28:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DIL1L06372; Wed, 13 Feb 2002 10:21:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DIKCL06360 for ; Wed, 13 Feb 2002 10:20:12 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DIPb120956; Wed, 13 Feb 2002 13:25:37 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DIPYd26428; Wed, 13 Feb 2002 19:25:34 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DIPAh03098; Wed, 13 Feb 2002 18:25:10 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS701C9>; Wed, 13 Feb 2002 18:25:31 -0000 Message-ID: <4103264BC8D3D51180B7002048400C450714FF@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Micah Bartell'" Cc: "'Jeff Learman'" , "'Tony Przygienda'" , "'Les Ginsberg'" , "'Tony Li'" , "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4BB.D0EE0B70" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 18:25:30 -0000 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_01C1B4BB.D0EE0B70 Content-Type: text/plain; charset="iso-8859-1" Appologies for the re-send, it was too long for the list server. Here is my first attempt:- Use of IS-IS ISH PDUs in IP Only Environments 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes how ISH PDUs are commonly used within the IS-IS protocol in IP Only environments for adjacency establishment over Point to Point circuits. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [1]. 3. The History of ISH The IS-IS protocol as defined in [2] and in [3] is intended for use with the Connectionless Network Service (CLNS). Due to the extensible nature of IS-IS it was possible to extend IS-IS to provide an integrated routing protocol which is Integrated IS-IS as defined in [1]. Integrated IS-IS may now be used to route CLNP, IPv4 and IPv6 packets. As the original intent of RFC 1195[1] was to provide a routing protocol capable of routing both CLNP and IPv4 packets, all of the requirements of [2] had to be retained. This included the use of ISH PDUs, which are needed to connect an OSI End System (ES) to an IS-IS router. An ES is the OSI equivalent to an IP host. For this reason RFC 1195 [1] states in section 5.1:- "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links." With time IP become the protocol of the Internet, and routers that could forward CLNP packets became increasingly rare. The majority of Integrated IS-IS routers were IP-only and thus incapable of forwarding traffic to OSI ESs. Many router vendors decided that ISHs were no longer required, as connection to an OSI ES was no longer a possibility, and did not implement transmission ISHs on point-to-point links. This did not create interoperability problems, as until 1993 ISO 10589 [2] stated that when a circuit is first enabled, an IIH PDU would be sent. The immediate transfer of IIHs effectively made redundant the ISH that had just been sent. However in 1993 an update to ISO 10589 was made to ISO 10589 which removed the immediate sending of IIH on enabling of a point-to-point circuit. This behaviour somewhat re-instated the ISH, giving it a new purpose as announcing the arrival of a router on the link in the absense of the immediate IIH. This new behaviour remains in the current Second Edition of ISO 10589 [3]. 4. Deployed IS-IS and ISH There are commonly three behaviours that are already deployed. These are:- 1. Routers that send ISH and IIH when a point-to-point circuit is enabled. 2. Routers that send only IIH when a point-to-point circuit is enabled. 3. Routers that send ISH when a point-to-point circuit is enabled, and then IIH some time later (when the iSISHelloTimer expires). This document does not specify which of these behaviours should be used, although an IS-IS router that can forward CLNP packets must clearly follow 1 or 3 corresponding to [1] or [2] respectively. This document advises that all three of these behaviours have been deployed and so MUST be accomodated by any new implementation attempting to form an adjacency with a deployed router. Another design decision is whether to receive and process ISH, or whether to ignore them. The consequence of ignoring ISH is that when connecting to a deployed router with behaviour 3, the router may not be recognised until the iSISHelloTimer has expired. This will only happen if the new router enables its point-to-point circuit before the existing router, resulting in it missing the IIH from the new one. This is a seperate design decision to sending ISHs. It is entirely possible to have an implementation that receives and processes ISHs as per [2] and [3], but which does not transmit them. Clearly an implementation that does not transmit ISHs MUST send an IIH upon enabling of a point-to-point circuit, as per [2]. 5. Security Considerations This document raises no new security issues for IS-IS. 6. References [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments" RFC 1195, December 1990 [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992 [3] ISO, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2001 ------_=_NextPart_001_01C1B4BB.D0EE0B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Question on the usage of ISH and P2PIIH

Appologies for the re-send, it was too long for the = list server.
Here is my first attempt:-

          &nb= sp;   Use of IS-IS ISH PDUs in IP Only Environments
          &nb= sp;           = <draft-ietf-isis-ish-00.txt>


1. Status of this Document

    This document is an Internet-Draft = and is in full conformance with all
    provisions of Section 10 of = RFC2026.

    Internet-Drafts are working = documents of the Internet Engineering Task
    Force (IETF), its areas, and its = working groups. Note that other groups
    may also distribute working = documents as Internet-Drafts.

    Internet-Drafts are draft = documents valid for a maximum of six months
    and may be updated, replaced, or = obsolete by other documents at any
    time. It is inappropriate to use = Internet-Drafts as reference material
    or to cite them other than as = "work in progress."

    The list of current = Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow = Directories can be accessed at
    http://www.ietf.org/shadow.html.

2. Abstract

    This document describes how ISH = PDUs are commonly used within the IS-IS
    protocol in IP Only environments = for adjacency establishment over Point
    to Point circuits.
  
    The IS-IS protocol is specified = in [2], with extensions for supporting
    IPv4 specified in [1].

3. The History of ISH

    The IS-IS protocol as defined in = [2] and in [3] is intended for use
    with the Connectionless Network = Service (CLNS).  Due to the extensible
    nature of IS-IS it was possible = to extend IS-IS to provide an integrated
    routing protocol which is = Integrated IS-IS as defined in [1].  Integrated
    IS-IS may now be used to route = CLNP, IPv4 and IPv6 packets.

    As the original intent of RFC = 1195[1] was to provide a routing protocol
    capable of routing both CLNP and = IPv4 packets, all of the requirements of [2]
    had to be retained.  This = included the use of ISH PDUs, which are needed to
    connect an OSI End System (ES) to = an IS-IS router.  An ES is the OSI
    equivalent to an IP host.

    For this reason RFC 1195 [1] = states in section 5.1:-

      "On = point-to-point links, the exchange of ISO 9542 ISHs = (intermediate
      system Hellos) is = used to initialize the link, and to allow each
      router to know if = there is a router on the other end of the link,
      before IS-IS Hellos = are exchanged. All routers implementing IS-IS
      (whether IP-only, = OSI-only, or dual), if they have any interfaces on
      point-to-point links, = must therefore be able to transmit ISO 9542
      ISHs on their = point-to-point links."

    With time IP become the protocol = of the Internet, and routers that could
    forward CLNP packets became = increasingly rare.  The majority of Integrated
    IS-IS routers were IP-only and = thus incapable of forwarding traffic to OSI
    ESs.

    Many router vendors decided that = ISHs were no longer required, as connection
    to an OSI ES was no longer a = possibility, and did not implement transmission
    ISHs on point-to-point = links.  This did not create interoperability
    problems, as until 1993 ISO 10589 = [2] stated that when a circuit is first
    enabled, an IIH PDU would be = sent.  The immediate transfer of IIHs
    effectively made redundant the = ISH that had just been sent.

    However in 1993 an update to ISO = 10589 was made to ISO 10589 which removed
    the immediate sending of IIH on = enabling of a point-to-point circuit.  This
    behaviour somewhat re-instated = the ISH, giving it a new purpose as announcing
    the arrival of a router on the = link in the absense of the immediate IIH.

    This new behaviour remains in the = current Second Edition of ISO 10589 [3].

4. Deployed IS-IS and ISH

    There are commonly three = behaviours that are already deployed.  These are:-

    1. Routers that send ISH and IIH = when a point-to-point circuit is enabled.

    2. Routers that send only IIH when = a point-to-point circuit is enabled.

    3. Routers that send ISH when a = point-to-point circuit is enabled, and then
       IIH some time = later (when the iSISHelloTimer expires).

    This document does not specify = which of these behaviours should be used,
    although an IS-IS router that can = forward CLNP packets must clearly follow
    1 or 3 corresponding to [1] or = [2] respectively.

    This document advises that all = three of these behaviours have been deployed
    and so MUST be accomodated by any = new implementation attempting to form an
    adjacency with a deployed = router.

    Another design decision is whether = to receive and process ISH, or whether to
    ignore them.  The = consequence of ignoring ISH is that when connecting to a
    deployed router with behaviour 3, = the router may not be recognised until
    the iSISHelloTimer has = expired.  This will only happen if the new router
    enables its point-to-point = circuit before the existing router, resulting in
    it missing the IIH from the new = one.

    This is a seperate design decision = to sending ISHs.  It is entirely possible
    to have an implementation that = receives and processes ISHs as per [2] and [3],
    but which does not transmit = them.

    Clearly an implementation that = does not transmit ISHs MUST send an IIH upon
    enabling of a point-to-point = circuit, as per [2].

5. Security Considerations

    This document raises no new = security issues for IS-IS.

6. References

    [1] R. Callon, "Use of OSI = IS-IS for Routing in TCP/IP and Dual
    Environments" RFC 1195, = December 1990

    [2] ISO, "Intermediate System = to Intermediate System Intra-
    Domain Routeing Exchange Protocol = for use in Conjunction with the
    Protocol for Providing the = Connectionless-mode Network Service (ISO
    8473)", ISO/IEC = 10589:1992

    [3] ISO, "Intermediate System = to Intermediate System Intra-
    Domain Routeing Exchange Protocol = for use in Conjunction with the
    Protocol for Providing the = Connectionless-mode Network Service (ISO
    8473)", ISO/IEC = 10589:2001

------_=_NextPart_001_01C1B4BB.D0EE0B70-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 13:37:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16668 for ; Wed, 13 Feb 2002 13:36:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DIT1L06435; Wed, 13 Feb 2002 10:29:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DIShL06423 for ; Wed, 13 Feb 2002 10:28:43 -0800 (PST) (envelope-from koen.vermeulen@alcatel.be) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g1DIYgl18348 for ; Wed, 13 Feb 2002 19:34:42 +0100 (MET) Message-ID: <3C6AB1BB.C1B8F412@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Isis-wg Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Regarding draft-ietf-isis-wg-mib-07.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 19:34:35 +0100 Content-Transfer-Encoding: 7bit Hello,

In the IS-IS mib in the 'Circuit Table' an entry called 'isisCircLocalId'
is described. It has the following description:

"An identification that can be used in protocol packets
to identify a circuit.  Values of isisCircLocalID do
not need to be unique.  They are only required to differ
on LANs where the Intermediate System is the Designated
Intermediate System."
According to the draft 'Maintaining more than 255 circuits in
IS-IS' (draft-ietf-isis-wg-255adj-02.txt), which was written some
time ago by Tony Przygienda and is already expired, the unique
circuit id for LAN Designated Intermediate Systems can be
separated between levels (this because a node can become DIS
at either level independently).
Because of this being independent of choosing a unique circuit
id between different levels, doesn't it make sense to have a
separate 'isisCircLocalId' per level? Otherwise, what local
circuit id has to be displayed in this object? The one from level 1
or the one from level 2?

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 14:10:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17724 for ; Wed, 13 Feb 2002 14:10:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DJ21L06624; Wed, 13 Feb 2002 11:02:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DJ1sL06612 for ; Wed, 13 Feb 2002 11:01:54 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Jeff Learman'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 14:07:17 -0500 > OK, I'll contribute text for the initial ISH thing, & you > guys can throw > darts at it. Stay tuned. > > Anyone volunteer to be editor? > > Anyone have a good list of things to include? I know there has been > some discussion but I didn't ever see it get any serious traction. > It might be a good idea for people to suggest items to include and > we can harangue about that. > > Regards, > Jeff I'll be happy to edit, if that is helpful. There are some items relating to adjacency bringup to damp the effects of link flapping that I would like to see documented as an implementation improvement. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 14:11:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17766 for ; Wed, 13 Feb 2002 14:11:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DJ31L06648; Wed, 13 Feb 2002 11:03:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DJ27L06626 for ; Wed, 13 Feb 2002 11:02:07 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1DJ88604927; Wed, 13 Feb 2002 11:08:08 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g1DJ88326823; Wed, 13 Feb 2002 11:08:08 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200202131908.g1DJ88326823@cirrus.juniper.net> From: Dave Katz To: christi@nortelnetworks.com CC: isis-wg@spider.juniper.net In-reply-to: <4103264BC8D3D51180B7002048400C450714F3@zhard0jd.europe.nortel.com> (christi@nortelnetworks.com) Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH References: <4103264BC8D3D51180B7002048400C450714F3@zhard0jd.europe.nortel.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 11:08:08 -0800 (PST) I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH. Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting? Yes, and hopefully legal, or the doc is already pointless. According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:- 1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway. 2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout? Angels are dancing on pins, I think. ;-) The creation of an adjacency on the receipt of an ISH is essentially meaningless, since it is not reflected in any outgoing IIH (as the IS type is not yet known) and so the "black box" test fails as there is no way to know that it happened, except by network management. The only function of the ISH in this case is to create the effectively null adjacency, because the verbiage in 10589 sort of hints that you're not supposed to create one on receipt of an IIH (though it doesn't explicitly say to ignore it, as far as I can see.) As for when IIHs are sent and not sent, this is effectively non-normative as well, since (a) the protocol would be correct even if IIHs were sent *only* on timers, though it would be slow to respond in some cases, and (b) there is no time-based acceptance criteria on IIHs, which means that you can send them any time you want and the protocol will still work. You never have to wait to send a hello (except for the overly restrictive requirement that you not send more than 1pps, which itself is unenforcable.) The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason. I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects. It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour. What am I missing here? Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs? You need ES functionality for network management (CMIP and TP4) if you were going to be a full-blown OSI router, the Tucker Torpedo of the networking world. Otherwise, the ISH serves no purpose at all. Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed. As far as I can tell, there is no practical difference between these two choices. What all this boils down to is that if an implementation is excessively pedantic and will not create an adjacency on receipt of an IIH with no preceding ISH, it will not interoperate with an implementation that does not send ISHs. I think that all we need to say is that an implementation must create an adjacency in response to a received IIH if none exists, and leave it at that. This is backward compatible with any behavior (or non-behavior) around the receipt of ISHs, and so nothing needs to be said about that, except to provide context. --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 15:10:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19481 for ; Wed, 13 Feb 2002 15:10:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DK21L06933; Wed, 13 Feb 2002 12:02:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DK1uL06921 for ; Wed, 13 Feb 2002 12:01:56 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] Regarding draft-ietf-isis-wg-mib-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 15:07:45 -0500 > [ We should have a ] > separate 'isisCircLocalId' per level > Koen Koen - I think you are right. I have just made the change. Look for it when .08 arrives. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 15:27:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19849 for ; Wed, 13 Feb 2002 15:27:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKK1L07031; Wed, 13 Feb 2002 12:20:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKJKL07016 for ; Wed, 13 Feb 2002 12:19:20 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.115] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA20069 for ; Wed, 13 Feb 2002 12:23:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1086522192.20020213122452@nexsi.com> To: "IS-IS-WG (E-mail)" Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 12:24:52 -0800 Content-Transfer-Encoding: 7bit Folks Vishwas, Russ, Radia, Mike and myself have been discussing with the WG chairs the idea of a document describing the differences between 10589 and running code for a while. We have the list of things to put there (ISH is just one item). Judging from the discussion on the list, there's more than sufficient interest in this, so I think it is a good idea to actually get this done. People who are game (I guess this includes Philip and both Jeffs ;), pls drop me a message cc'ing Russ, I'll setup a mailing list and we'll go from there. Regards. -- Alex Zinin _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 15:36:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20066 for ; Wed, 13 Feb 2002 15:36:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKT1L07099; Wed, 13 Feb 2002 12:29:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKSxL07087 for ; Wed, 13 Feb 2002 12:28:59 -0800 (PST) (envelope-from mbartell@cisco.com) Received: from MBARTELL-W2K.cisco.com (mbartell-w2k.cisco.com [64.101.142.68]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA15439; Wed, 13 Feb 2002 12:34:36 -0800 (PST) Message-Id: <4.3.2.7.2.20020213142634.016e9318@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: Micah Bartell Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: "'Jeff Learman'" , "'Tony Przygienda'" , "'Les Ginsberg'" , "'Tony Li'" , "'isis-wg@spider.juniper.net'" In-Reply-To: <4103264BC8D3D51180B7002048400C450714FF@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 14:34:35 -0600 Alright....I went back and did a rehash of your doco and mine. Integrated parts and made sure I got Dave's last comments addressed. At this point 10589:2001 is not a formal IS, so I would rather just reference 10589:1992 and RFC 1195. I would rather see a quick synopsis of what is required to be compliant than an explanation of the various implementations. If you follow the BP for IIH and ISH handling, you will be compliant with all of the implementations. I think the point here is to identify where the issue is, RFC 1195 section 5.1 and 10589 Section 8.2.4. Why it says what it does, when we do not need to strictly adhere, and in what manner we do not need to adhere. /mpb IS-IS Adjacency Establishment in IP Only Environments 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes a modification to the IS-IS protocol in IP Only environments for adjacency establishment over Point to Point circuits. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [1]. This draft describes a modification to the IS-IS protocol, which will allow an IS-IS adjacency to be established over Point to Point circuits without the use of an Intermediate System Hello PDU (ISH). 3. Introduction The IS-IS protocol as defined in [2] was intended for use with the Connectionless Network Service (CLNS). The extensible nature of IS-IS enabled IS-IS to be extended to provide multiprotocol support in an integrated routing protocol, Integrated IS-IS, as defined in [1]. Integrated IS-IS now supports reachability information for CLNS, IPv4, and IPv6. The original intent of [1] was to provide a routing protocol capable of handling both CLNS and IPv4 reachability information. The need to support CLNS reachability information required that an ISH be issued to detect End Systems (ES) and initiate the formation of an ES-IS adjacency. For this reason section 5.1 of [1] states: "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links." Section 5.1 of [1] re-enforces the need to comply with section 8.2.4 of [2]. This requirement was defined when the industry mindset was that of dual environments being the general case. The general case has instead shifted to IP Only environments. In an IP Only environment, there is no need to issue an ISH PDU over a Point to Point circuit because there are no End Systems with which to form an ES-IS adjacency. [2] requires that an ISH be received in order to issue an IIH PDU. 4. Best Common Practice An IP Only implementation has no need to issue an ISH PDU as described in section 8.2.4 of [2]. An IP Only implementation MAY issue an IIH PDU when a Point to Point circuit transitions into an "Up" state to initiate the formation of an IS-IS adjacency. An IP Only implementation SHOULD accept an IIH to initialize an adjacency regardless of an ISH having been issued. The IIH PDU SHOULD still be issued in conformance with section 8.2.4 of [2] with the exception of the requirement for reception of an ISH PDU. An implementation that supports the forwarding of CLNS PDU's MUST act in full accordance with section 8.2.4 of [2] when CLNS functionality is enabled, including the initial issuance of an ISH PDU. 5. Security Considerations This document raises no new security issues for IS-IS. 6. References [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments" RFC 1195, December 1990 [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 15:44:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20260 for ; Wed, 13 Feb 2002 15:44:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKb1L07197; Wed, 13 Feb 2002 12:37:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKalL07185 for ; Wed, 13 Feb 2002 12:36:47 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA08372; Wed, 13 Feb 2002 12:42:19 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 12:42:19 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F7C0@avalon.pluris.com> From: Les Ginsberg To: "'Philip Christian'" , "'mike shand'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4CE.EDA21690" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 12:42:18 -0800 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_01C1B4CE.EDA21690 Content-Type: text/plain; charset="iso-8859-1" The original text in 10589:1992 8.2.3 caused confusion because it said to send IIHs when "the circuit is first enabled". This suggested that there was no need to wait for receipt of an ISH. This was not the intended behavior. A Defect Report was filed in April of 1993 (JTC1/SC6/WG2/N523 - for those of you lucky enough to have a vintage copy) in which this confusion was discussed. My transcribed quote (no electronic copy I am afraid) reads: "There seems to be a problem with the 10589 description of the initialization of pt-pt circuits in clause 8.2. In ISO 9542 the IS starts off by sending an ISH PDU and only when the IS has detected that the other end is an IS (by receipt of its ISH PDU) should the IS start sending IIH PDUs. In 10589 there seems to be an anomaly. 8.2.2 says what you do when you receive an ISH, but nothing tells you to send them. 8.2.3 tells you to send IIH PDUs all the time. It looks as if some attempt has been made to remove the initial ISH exchange step, but it hasn't been completed. The standard needs to specify that upon circuit initialization the IS sends an ISH PDU, and sends IIH PDUs in response to receipt of ISH PDUs." With that in mind, two changes were introduced (refer to 10589:2001 draft for full text): 1)New section 8.2.3 was added to explicitly state that an ISH needed to be sent when a point-point circuit was first enabled. Additional wording was added to this section to clarify issues that arose in SIF a few years ago regarding whether ISHs should continue to be periodically sent after an adjacency was up. 2)8.2.4a (renumbered from 8.2.3.a in 1992 spec) was changed to indicate that an IIH should be sent upon receipt of an ISH rather than when the circuit is first enabled. The issue that still seems to confuse some folks is 8.2.4b which says to send IIHs when the "iSISHelloTimer expires". What is not explicity stated (but sort of naturally falls out when you implement it (he said foolishly)) is that you don't start running the "iSISHelloTimer" until you send your first IIH - which would come AFTER receiving an ISH. It might have been clearer if some statement were explicutly made to say that the timer is not started when the circuit is enabled - but I believe that was what is meant both by the current and the original text. I hope this at least clarifies the points raised below. Les -----Original Message----- From: Philip Christian [mailto:christi@nortelnetworks.com] Sent: Wednesday, February 13, 2002 7:05 AM To: 'mike shand' Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH From ISO/IEC 10589:1992 8.2.3 "8.2.3 Sending point-to-point IIH PDUs An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the circuit is first enabled; or b) whenever iSISHelloTimer expires" In ISO/IEC 10589:2001 8.2.4 this becomes "8.2.4 Sending point-to-point IIH PDUs An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the IS receives an ISH PDU b) whenever iSISHelloTimer expires" So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System. One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end. At least that is my enterpretation of it. I'd love to know the reasoning behind the change. Philip -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: 13 February 2002 13:22 To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH At 13:15 13/02/2002 +0000, Philip Christian wrote: So that explains why an OSI router needs to send ISH, as there might be an ES that needs it. It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard? Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH). But that really doesn't apply any more, even if it ever did. Mike ------_=_NextPart_001_01C1B4CE.EDA21690 Content-Type: text/html; charset="iso-8859-1"

The original text in 10589:1992 8.2.3 caused confusion because it said to send IIHs when "the circuit is first enabled". This suggested that there was no need to wait for receipt of an ISH. This was not the intended behavior. A Defect Report was filed in April of 1993 (JTC1/SC6/WG2/N523 - for those of you lucky enough to have a vintage copy) in which this confusion was discussed. My transcribed quote (no electronic copy I am afraid) reads:
 
"There seems to be a problem with the 10589 description of the initialization of pt-pt circuits in clause 8.2. In ISO 9542 the IS starts off by sending an ISH PDU and only when the IS has detected that the other end is an IS (by receipt of its ISH PDU) should the IS start sending IIH PDUs. In 10589 there seems to be an anomaly. 8.2.2 says what you do when you receive an ISH, but nothing tells you to send them. 8.2.3 tells you to send IIH PDUs all the time. It looks as if some attempt has been made to remove the initial ISH exchange step, but it hasn't been completed. The standard needs to specify that upon circuit initialization the IS sends an ISH PDU, and sends IIH PDUs in response to receipt of ISH PDUs."
 
With that in mind, two changes were introduced (refer to 10589:2001 draft for full text):
 
1)New section 8.2.3 was added to explicitly state that an ISH needed to be sent when a point-point circuit was first enabled. Additional wording was added to this section to clarify issues that arose in SIF a few years ago regarding whether ISHs should continue to be periodically sent after an adjacency was up.
 
2)8.2.4a (renumbered from 8.2.3.a in 1992 spec) was changed to indicate that an IIH should be sent upon receipt of an ISH rather than when the circuit is first enabled.
 
The issue that still seems to confuse some folks is 8.2.4b which says to send IIHs when the "iSISHelloTimer expires". What is not explicity stated (but sort of naturally falls out when you implement it (he said foolishly)) is that you don't start running the "iSISHelloTimer" until you send your first IIH - which would come AFTER receiving an ISH. It might have been clearer if some statement were explicutly made to say that the timer is not started when the circuit is enabled - but I believe that was what is meant both by the current and the original text.
 
I hope this at least clarifies the points raised below.
 
 
   Les
 
-----Original Message-----
From: Philip Christian [mailto:christi@nortelnetworks.com]
Sent: Wednesday, February 13, 2002 7:05 AM
To: 'mike shand'
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

From ISO/IEC 10589:1992 8.2.3
"8.2.3 Sending point-to-point IIH PDUs
An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the circuit is first enabled; or
b) whenever iSISHelloTimer expires"
 
In ISO/IEC 10589:2001 8.2.4 this becomes
"8.2.4 Sending point-to-point IIH PDUs
An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the IS receives an ISH PDU
b) whenever iSISHelloTimer expires"
 
So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System.
 
One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end.
 
At least that is my enterpretation of it.
 
I'd love to know the reasoning behind the change.
 
Philip
 
 
 
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

At 13:15 13/02/2002 +0000, Philip Christian wrote:
So that explains why an OSI router needs to send ISH, as there might be an ES that needs it.
It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard?

Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH).

But that really doesn't apply any more, even if it ever did.

        Mike


------_=_NextPart_001_01C1B4CE.EDA21690-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 15:59:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20570 for ; Wed, 13 Feb 2002 15:59:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKq1L07287; Wed, 13 Feb 2002 12:52:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from sundmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DKppL07275 for ; Wed, 13 Feb 2002 12:51:51 -0800 (PST) (envelope-from tli@procket.com) Received: from miata.procket.com (unknown [10.1.1.1]) by sundmz1.procket.com (Postfix) with ESMTP id A219C23C3E; Wed, 13 Feb 2002 12:49:05 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g1DKvqqu011325; Wed, 13 Feb 2002 12:57:53 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g1DKvqc5011279; Wed, 13 Feb 2002 12:57:52 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15466.54096.555551.223961@alpha-tli.procket.com> To: Dave Katz Cc: christi@nortelnetworks.com, isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH In-Reply-To: <200202131908.g1DJ88326823@cirrus.juniper.net> References: <4103264BC8D3D51180B7002048400C450714F3@zhard0jd.europe.nortel.com> <200202131908.g1DJ88326823@cirrus.juniper.net> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 12:57:52 -0800 Content-Transfer-Encoding: 7bit | What all this boils down to is that if an implementation is | excessively pedantic and will not create an adjacency on receipt of an | IIH with no preceding ISH, it will not interoperate with an | implementation that does not send ISHs. I think that all we need to | say is that an implementation must create an adjacency in response to | a received IIH if none exists, and leave it at that. This is backward | compatible with any behavior (or non-behavior) around the receipt of | ISHs, and so nothing needs to be said about that, except to provide | context. Amen. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 16:16:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20939 for ; Wed, 13 Feb 2002 16:16:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DL91L07404; Wed, 13 Feb 2002 13:09:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DL8RL07390 for ; Wed, 13 Feb 2002 13:08:27 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1DLEi704904; Wed, 13 Feb 2002 16:14:44 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAT43537; Wed, 13 Feb 2002 16:14:26 -0500 (EST) Message-Id: <4.3.2.7.2.20020213154656.01d18fe0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Micah Bartell From: Jeff Learman Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: isis-wg@spider.juniper.net In-Reply-To: <4.3.2.7.2.20020213142634.016e9318@cactus.cisco.com> References: <4103264BC8D3D51180B7002048400C450714FF@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 16:14:23 -0500 At 03:34 PM 2/13/2002, Micah Bartell wrote: >Alright....I went back and did a rehash of your doco and mine. Integrated parts and made sure I got Dave's last comments addressed. > >At this point 10589:2001 is not a formal IS, so I would rather just reference 10589:1992 and RFC 1195. > >I would rather see a quick synopsis of what is required to be compliant than an explanation of the various implementations. If you follow the BP for IIH and ISH handling, you will be compliant with all of the implementations. > >I think the point here is to identify where the issue is, RFC 1195 section 5.1 and 10589 Section 8.2.4. Why it says what it does, when we do not need to strictly adhere, and in what manner we do not need to adhere. > >/mpb > > > > IS-IS Adjacency Establishment in IP Only Environments > > > >1. Status of this Document > > This document is an Internet-Draft and is in full conformance with all > provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. Note that other groups > may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsolete by other documents at any > time. It is inappropriate to use Internet-Drafts as reference material > or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > >2. Abstract > > This document describes a modification to the IS-IS protocol in IP Only > environments for adjacency establishment over Point to Point circuits. > The IS-IS protocol is specified in [2], with extensions for supporting > IPv4 specified in [1]. > > This draft describes a modification to the IS-IS protocol, which will > allow an IS-IS adjacency to be established over Point to Point circuits > without the use of an Intermediate System Hello PDU (ISH). > >3. Introduction > > The IS-IS protocol as defined in [2] was intended for use with the > Connectionless Network Service (CLNS). The extensible nature of IS-IS > enabled IS-IS to be extended to provide multiprotocol support in an > integrated routing protocol, Integrated IS-IS, as defined in [1]. > Integrated IS-IS now supports reachability information for CLNS, IPv4, > and IPv6. > > The original intent of [1] was to provide a routing protocol capable > of handling both CLNS and IPv4 reachability information. > The need to > support CLNS reachability information required that an ISH be issued > to detect End Systems (ES) and initiate the formation of an ES-IS > adjacency. Not quite. You don't send an ISH to detect an ES. You send an ISH so that the ES knows you're a router (if it is an ES) and the *ES* forms an ES-IS adjacency. I would revise this to say, To support the possibility of a CLNS ES attached on a PTP link, ISs are required to send ISH PDUs, and are not to send IIH PDUs before receiving an ISH from the peer. > For this reason section 5.1 of [1] states: > > "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate > system Hellos) is used to initialize the link, and to allow each > router to know if there is a router on the other end of the link, > before IS-IS Hellos are exchanged. All routers implementing IS-IS > (whether IP-only, OSI-only, or dual), if they have any interfaces on > point-to-point links, must therefore be able to transmit ISO 9542 > ISHs on their point-to-point links." > > Section 5.1 of [1] re-enforces the need to comply with section 8.2.4 > of [2]. See note below about TC1. >This requirement was defined when the industry mindset was > that of dual environments being the general case. The general case > has instead shifted to IP Only environments. I don't think we need to talk about mindset, and there are members of this list who consider dual environments very important. All you need is to begin the next sentence with "However,". > In an IP Only environment, there is no need to issue an ISH PDU over a > Point to Point circuit because there are no End Systems with which to > form an ES-IS adjacency. >[2] requires that an ISH be received in order > to issue an IIH PDU. This is inaccurate unless you specify [2] as including TC1. 10589:1992 says, in 8.2.3 (renumbered by TC1 as 8.2.4) The IIH PDU shall be sent when: a) the circuit is first enabled. It would be more accurate to say that [2] allows sending the IIH first, but this was a mistake that was corrected in [3], and is now being allowed again in certain circumstances. [3] ISO, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473) Technical Corrigendum 1", ISO/IEC 10589:1992 TC1, May 1993. Plus, you would need to change [2] in text below to [3]. >4. Best Common Practice > > An IP Only implementation has no need to issue an ISH PDU as described in > section 8.2.4 of [2]. An IP Only implementation MAY issue an IIH PDU > when a Point to Point circuit transitions into an "Up" state to > initiate the formation of an IS-IS adjacency. An IP Only implementation > SHOULD accept an IIH to initialize an adjacency regardless of an ISH > having been issued. The IIH PDU SHOULD still be issued in conformance > with section 8.2.4 of [2] with the exception of the requirement for > reception of an ISH PDU. > > An implementation that supports the forwarding of CLNS PDU's MUST act in > full accordance with section 8.2.4 of [2] when CLNS functionality is > enabled, including the initial issuance of an ISH PDU. An implementation that supports CLNP should be allowed to send an IIH after receiving one, but this is not permitted by [3]. After receiving the IIH, we know that the neighbor is clearly an IS, so there is no need to wait for an ESH or ISH. I would say: An implementation that does not support attachments to CLNP End Systems via PTP links MAY send an IIH without waiting for an ISH, and MAY omit sending an ISH. An implementation that does support attachments to CLNP End Systems via PTP links MUST send an ISH when a PTP circuit is established, and MAY send an IIH after receiving an IIH on the link. >5. Security Considerations > > This document raises no new security issues for IS-IS. > >6. References > > [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual > Environments" RFC 1195, December 1990 > > [2] ISO, "Intermediate System to Intermediate System Intra- > Domain Routeing Exchange Protocol for use in Conjunction with the > Protocol for Providing the Connectionless-mode Network Service (ISO > 8473)", ISO/IEC 10589:1992 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 16:47:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22226 for ; Wed, 13 Feb 2002 16:47:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DLd1L07551; Wed, 13 Feb 2002 13:39:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DLcnL07539 for ; Wed, 13 Feb 2002 13:38:49 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DLiW106720; Wed, 13 Feb 2002 16:44:32 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DLiPd08680; Wed, 13 Feb 2002 22:44:29 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DLi0h13357; Wed, 13 Feb 2002 21:44:00 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS70G7B>; Wed, 13 Feb 2002 21:44:23 -0000 Message-ID: <4103264BC8D3D51180B7002048400C45071500@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Les Ginsberg'" , "'mike shand'" , "'Dave Katz'" , "'Jeff Learman'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4D7.986CF3D0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 21:44:21 -0000 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_01C1B4D7.986CF3D0 Content-Type: text/plain; charset="iso-8859-1" Les, I also just read this in 10589:2001 "9.7 Point-to-point IS to IS hello PDU This PDU is transmitted by Intermediate systems on nonbroadcast circuits, after receiving an ISH PDU from the neighbour system." This would appear to back you up, but it really is a shame that it wasn't more clearly stated. I might not be very popular for saying this, but there does then appear to be a fundamental incompatibility. You have one router that conforms to 10589:2001 that will not send IIH until it gets an ISH, and sits there sending out ISHs. Then you have another that doesn't send ISHs and sits there waiting for an IIH that never comes. One thing that I still don't understand is this: if a 10589:2001 implementation receives an IIH but no ISH, does it still sit there determined not to reply? It would appear that it still has to perform the IIH acceptance tests, doesn't it? Will it actually bring up an adjacency and still not send an IIH back? There seems to be a contradiction here. We seem to have a choice here, either 1. Go against 10589:2001 and explicitly state that if you get an IIH then you MUST send an IIH back and perform the IIH acceptance tests (plus three way handshake if you both support). If we go against ISO and RFC 1195 (clarify ;-) ) then it needs to be very clearly stated that this is what is happening. or 2. Say that routers MUST send and receive/process ISHs, whether or not they forward CLNP or not. I think that only one of these actually guarantees interop. There is the third option of course, make "1" AND "2" mandatory, which upsets almost everyone but doubly guarantees interop. Now there's a thought. Philip -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: 13 February 2002 20:42 To: Christian, Philip [HAL02:GI50:EXCH]; 'mike shand' Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH The original text in 10589:1992 8.2.3 caused confusion because it said to send IIHs when "the circuit is first enabled". This suggested that there was no need to wait for receipt of an ISH. This was not the intended behavior. A Defect Report was filed in April of 1993 (JTC1/SC6/WG2/N523 - for those of you lucky enough to have a vintage copy) in which this confusion was discussed. My transcribed quote (no electronic copy I am afraid) reads: "There seems to be a problem with the 10589 description of the initialization of pt-pt circuits in clause 8.2. In ISO 9542 the IS starts off by sending an ISH PDU and only when the IS has detected that the other end is an IS (by receipt of its ISH PDU) should the IS start sending IIH PDUs. In 10589 there seems to be an anomaly. 8.2.2 says what you do when you receive an ISH, but nothing tells you to send them. 8.2.3 tells you to send IIH PDUs all the time. It looks as if some attempt has been made to remove the initial ISH exchange step, but it hasn't been completed. The standard needs to specify that upon circuit initialization the IS sends an ISH PDU, and sends IIH PDUs in response to receipt of ISH PDUs." With that in mind, two changes were introduced (refer to 10589:2001 draft for full text): 1)New section 8.2.3 was added to explicitly state that an ISH needed to be sent when a point-point circuit was first enabled. Additional wording was added to this section to clarify issues that arose in SIF a few years ago regarding whether ISHs should continue to be periodically sent after an adjacency was up. 2)8.2.4a (renumbered from 8.2.3.a in 1992 spec) was changed to indicate that an IIH should be sent upon receipt of an ISH rather than when the circuit is first enabled. The issue that still seems to confuse some folks is 8.2.4b which says to send IIHs when the "iSISHelloTimer expires". What is not explicity stated (but sort of naturally falls out when you implement it (he said foolishly)) is that you don't start running the "iSISHelloTimer" until you send your first IIH - which would come AFTER receiving an ISH. It might have been clearer if some statement were explicutly made to say that the timer is not started when the circuit is enabled - but I believe that was what is meant both by the current and the original text. I hope this at least clarifies the points raised below. Les -----Original Message----- From: Philip Christian [mailto:christi@nortelnetworks.com] Sent: Wednesday, February 13, 2002 7:05 AM To: 'mike shand' Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH From ISO/IEC 10589:1992 8.2.3 "8.2.3 Sending point-to-point IIH PDUs An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the circuit is first enabled; or b) whenever iSISHelloTimer expires" In ISO/IEC 10589:2001 8.2.4 this becomes "8.2.4 Sending point-to-point IIH PDUs An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the IS receives an ISH PDU b) whenever iSISHelloTimer expires" So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System. One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end. At least that is my enterpretation of it. I'd love to know the reasoning behind the change. Philip -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: 13 February 2002 13:22 To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH At 13:15 13/02/2002 +0000, Philip Christian wrote: So that explains why an OSI router needs to send ISH, as there might be an ES that needs it. It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard? Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH). But that really doesn't apply any more, even if it ever did. Mike ------_=_NextPart_001_01C1B4D7.986CF3D0 Content-Type: text/html; charset="iso-8859-1"
Les,
 
I also just read this in 10589:2001
 
"9.7 Point-to-point IS to IS hello PDU
This PDU is transmitted by Intermediate systems on
nonbroadcast circuits, after receiving an ISH PDU from the
neighbour system."
 
This would appear to back you up, but it really is a shame that it wasn't more clearly stated.
 
I might not be very popular for saying this, but there does then appear to be a fundamental incompatibility.
 
You have one router that conforms to 10589:2001 that will not send IIH until it gets an ISH, and sits there sending out ISHs.
Then you have another that doesn't send ISHs and sits there waiting for an IIH that never comes.
 
One thing that I still don't understand is this: if a 10589:2001 implementation receives an IIH but no ISH, does it still sit there determined not to reply?
It would appear that it still has to perform the IIH acceptance tests, doesn't it?
Will it actually bring up an adjacency and still not send an IIH back?
There seems to be a contradiction here.
 
We seem to have a choice here, either
 
1. Go against 10589:2001 and explicitly state that if you get an IIH then you MUST send an IIH back and perform the IIH acceptance tests (plus three way handshake if you both support). If we go against ISO and RFC 1195 (clarify ;-) ) then it needs to be very clearly stated that this is what is happening.
 
or
 
2. Say that routers MUST send and receive/process ISHs, whether or not they forward CLNP or not.
 
I think that only one of these actually guarantees interop.
 
There is the third option of course, make "1" AND "2" mandatory, which upsets almost everyone but doubly guarantees interop. Now there's a thought.
 
Philip
-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: 13 February 2002 20:42
To: Christian, Philip [HAL02:GI50:EXCH]; 'mike shand'
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

The original text in 10589:1992 8.2.3 caused confusion because it said to send IIHs when "the circuit is first enabled". This suggested that there was no need to wait for receipt of an ISH. This was not the intended behavior. A Defect Report was filed in April of 1993 (JTC1/SC6/WG2/N523 - for those of you lucky enough to have a vintage copy) in which this confusion was discussed. My transcribed quote (no electronic copy I am afraid) reads:
 
"There seems to be a problem with the 10589 description of the initialization of pt-pt circuits in clause 8.2. In ISO 9542 the IS starts off by sending an ISH PDU and only when the IS has detected that the other end is an IS (by receipt of its ISH PDU) should the IS start sending IIH PDUs. In 10589 there seems to be an anomaly. 8.2.2 says what you do when you receive an ISH, but nothing tells you to send them. 8.2.3 tells you to send IIH PDUs all the time. It looks as if some attempt has been made to remove the initial ISH exchange step, but it hasn't been completed. The standard needs to specify that upon circuit initialization the IS sends an ISH PDU, and sends IIH PDUs in response to receipt of ISH PDUs."
 
With that in mind, two changes were introduced (refer to 10589:2001 draft for full text):
 
1)New section 8.2.3 was added to explicitly state that an ISH needed to be sent when a point-point circuit was first enabled. Additional wording was added to this section to clarify issues that arose in SIF a few years ago regarding whether ISHs should continue to be periodically sent after an adjacency was up.
 
2)8.2.4a (renumbered from 8.2.3.a in 1992 spec) was changed to indicate that an IIH should be sent upon receipt of an ISH rather than when the circuit is first enabled.
 
The issue that still seems to confuse some folks is 8.2.4b which says to send IIHs when the "iSISHelloTimer expires". What is not explicity stated (but sort of naturally falls out when you implement it (he said foolishly)) is that you don't start running the "iSISHelloTimer" until you send your first IIH - which would come AFTER receiving an ISH. It might have been clearer if some statement were explicutly made to say that the timer is not started when the circuit is enabled - but I believe that was what is meant both by the current and the original text.
 
I hope this at least clarifies the points raised below.
 
 
   Les
 
-----Original Message-----
From: Philip Christian [mailto:christi@nortelnetworks.com]
Sent: Wednesday, February 13, 2002 7:05 AM
To: 'mike shand'
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

From ISO/IEC 10589:1992 8.2.3
"8.2.3 Sending point-to-point IIH PDUs
An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the circuit is first enabled; or
b) whenever iSISHelloTimer expires"
 
In ISO/IEC 10589:2001 8.2.4 this becomes
"8.2.4 Sending point-to-point IIH PDUs
An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the IS receives an ISH PDU
b) whenever iSISHelloTimer expires"
 
So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System.
 
One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end.
 
At least that is my enterpretation of it.
 
I'd love to know the reasoning behind the change.
 
Philip
 
 
 
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

At 13:15 13/02/2002 +0000, Philip Christian wrote:
So that explains why an OSI router needs to send ISH, as there might be an ES that needs it.
It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard?

Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH).

But that really doesn't apply any more, even if it ever did.

        Mike


------_=_NextPart_001_01C1B4D7.986CF3D0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 17:03:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22504 for ; Wed, 13 Feb 2002 17:03:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DLu1L07662; Wed, 13 Feb 2002 13:56:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DLtBL07650 for ; Wed, 13 Feb 2002 13:55:11 -0800 (PST) (envelope-from cast@allegronetworks.com) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id <137B5W37>; Wed, 13 Feb 2002 14:00:07 -0800 Message-ID: From: Neal Castagnoli To: "'Philip Christian'" , "'Les Ginsberg'" , "'mike shand'" , "'Dave Katz'" , "'Jeff Learman'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 14:00:04 -0800 Phil, > 2. Say that routers MUST send and receive/process ISHs, whether or not they > forward CLNP or not. I think the implementation that transmits the ISH until the adjacency is in the "UP" state but that doesn't process received ISHs (transmitting IIHs from the get-go) will interoperate even with strict 10589 version 2 implementations. Not processing received ISHs removes most of the trouble of processing another protocol, which would open up all the parsing issues and potential bugs, etc. --Neal _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 17:36:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23158 for ; Wed, 13 Feb 2002 17:36:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DMS1L07827; Wed, 13 Feb 2002 14:28:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DMRAL07815 for ; Wed, 13 Feb 2002 14:27:10 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id OAA11566; Wed, 13 Feb 2002 14:32:47 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 14:32:47 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F7C3@avalon.pluris.com> From: Les Ginsberg To: "'Philip Christian'" , Les Ginsberg , "'mike shand'" , "'Dave Katz'" , "'Jeff Learman'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4DE.5C9543B0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 14:32:47 -0800 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_01C1B4DE.5C9543B0 Content-Type: text/plain; charset="iso-8859-1" Philip - The revisions in ISO 10589:2001 relevant to this topic were never intended to "change" the way adjacency formation worked. Rather, they were intended to clarify the original intent. In that context, it does not help to create two sets of conformance criteria, one for 1992 compatibility and one for 2001 compatibility. Certainly, it is understandable that interpretations of the text might differ. That is precisely why the language was altered - in the hopes that the originally intended behavior would be better understood. Now if you have two implementations and the understanding of the spec on the part of the implementors differs in such a way that you end up with a behavioral incompatibility, that is a real world problem that has to be addressed. But please don't put us in the position of trying to maintain compatibility to two different spec interpretations as if the protocol was intentionally altered between 1992/2001 in an incompatible way. It wasn't. More comments below. Les -----Original Message----- From: Philip Christian [mailto:christi@nortelnetworks.com] Sent: Wednesday, February 13, 2002 1:44 PM To: 'Les Ginsberg'; 'mike shand'; 'Dave Katz'; 'Jeff Learman' Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Les, I also just read this in 10589:2001 "9.7 Point-to-point IS to IS hello PDU This PDU is transmitted by Intermediate systems on nonbroadcast circuits, after receiving an ISH PDU from the neighbour system." This would appear to back you up, but it really is a shame that it wasn't more clearly stated. I might not be very popular for saying this, but there does then appear to be a fundamental incompatibility. You have one router that conforms to 10589:2001 that will not send IIH until it gets an ISH, and sits there sending out ISHs. Then you have another that doesn't send ISHs and sits there waiting for an IIH that never comes. [Les Ginsberg] Yes - this is the essence of the incompatibility - but it is NOT a 10589:2001 issue. In the IP world, some implementations simply don't send ISHs - and therefore you can get into this deadlock unless the other end is willing to start sending IIHs on receipt of an IIH even without an ISH. That is precisely the issue which we are trying to clarify with a new RFC. One thing that I still don't understand is this: if a 10589:2001 implementation receives an IIH but no ISH, does it still sit there determined not to reply? [Les Ginsberg] Yes, a strictly conformant implementation would do that. That is true of a strictly conformant 10589 implementation regardless of spec vintage. Please do not wordsmith me here. Yes, the 1992 spec wasn't worded as well as it might be - but I think there is clear historical evidence for what was intended. It would appear that it still has to perform the IIH acceptance tests, doesn't it? Will it actually bring up an adjacency and still not send an IIH back? There seems to be a contradiction here. We seem to have a choice here, either 1. Go against 10589:2001 and explicitly state that if you get an IIH then you MUST send an IIH back and perform the IIH acceptance tests (plus three way handshake if you both support). If we go against ISO and RFC 1195 (clarify ;-) ) then it needs to be very clearly stated that this is what is happening. or 2. Say that routers MUST send and receive/process ISHs, whether or not they forward CLNP or not. I think that only one of these actually guarantees interop. [Les Ginsberg] No. That is NOT necessary. All that is necessary is that an implementation relax its requirements so that it will create an adjacency (in initialising state) and start sending IIHs on receipt of an IIH even in the absence of an ISH. There is the third option of course, make "1" AND "2" mandatory, which upsets almost everyone but doubly guarantees interop. Now there's a thought. [Les Ginsberg] YOu are right - such a suggestion is likely to make you very unpopular. Philip -----Original Message----- From: Les Ginsberg [mailto:ginsberg@pluris.com] Sent: 13 February 2002 20:42 To: Christian, Philip [HAL02:GI50:EXCH]; 'mike shand' Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH The original text in 10589:1992 8.2.3 caused confusion because it said to send IIHs when "the circuit is first enabled". This suggested that there was no need to wait for receipt of an ISH. This was not the intended behavior. A Defect Report was filed in April of 1993 (JTC1/SC6/WG2/N523 - for those of you lucky enough to have a vintage copy) in which this confusion was discussed. My transcribed quote (no electronic copy I am afraid) reads: "There seems to be a problem with the 10589 description of the initialization of pt-pt circuits in clause 8.2. In ISO 9542 the IS starts off by sending an ISH PDU and only when the IS has detected that the other end is an IS (by receipt of its ISH PDU) should the IS start sending IIH PDUs. In 10589 there seems to be an anomaly. 8.2.2 says what you do when you receive an ISH, but nothing tells you to send them. 8.2.3 tells you to send IIH PDUs all the time. It looks as if some attempt has been made to remove the initial ISH exchange step, but it hasn't been completed. The standard needs to specify that upon circuit initialization the IS sends an ISH PDU, and sends IIH PDUs in response to receipt of ISH PDUs." With that in mind, two changes were introduced (refer to 10589:2001 draft for full text): 1)New section 8.2.3 was added to explicitly state that an ISH needed to be sent when a point-point circuit was first enabled. Additional wording was added to this section to clarify issues that arose in SIF a few years ago regarding whether ISHs should continue to be periodically sent after an adjacency was up. 2)8.2.4a (renumbered from 8.2.3.a in 1992 spec) was changed to indicate that an IIH should be sent upon receipt of an ISH rather than when the circuit is first enabled. The issue that still seems to confuse some folks is 8.2.4b which says to send IIHs when the "iSISHelloTimer expires". What is not explicity stated (but sort of naturally falls out when you implement it (he said foolishly)) is that you don't start running the "iSISHelloTimer" until you send your first IIH - which would come AFTER receiving an ISH. It might have been clearer if some statement were explicutly made to say that the timer is not started when the circuit is enabled - but I believe that was what is meant both by the current and the original text. I hope this at least clarifies the points raised below. Les -----Original Message----- From: Philip Christian [mailto:christi@nortelnetworks.com] Sent: Wednesday, February 13, 2002 7:05 AM To: 'mike shand' Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH From ISO/IEC 10589:1992 8.2.3 "8.2.3 Sending point-to-point IIH PDUs An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the circuit is first enabled; or b) whenever iSISHelloTimer expires" In ISO/IEC 10589:2001 8.2.4 this becomes "8.2.4 Sending point-to-point IIH PDUs An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the IS receives an ISH PDU b) whenever iSISHelloTimer expires" So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System. One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end. At least that is my enterpretation of it. I'd love to know the reasoning behind the change. Philip -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: 13 February 2002 13:22 To: Christian, Philip [HAL02:GI50:EXCH] Cc: 'isis-wg@spider.juniper.net' Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH At 13:15 13/02/2002 +0000, Philip Christian wrote: So that explains why an OSI router needs to send ISH, as there might be an ES that needs it. It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard? Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH). But that really doesn't apply any more, even if it ever did. Mike ------_=_NextPart_001_01C1B4DE.5C9543B0 Content-Type: text/html; charset="iso-8859-1"
Philip -
 
The revisions in ISO 10589:2001 relevant to this topic were never intended to "change" the way adjacency formation worked. Rather, they were intended to clarify the original intent. In that context, it does not help to create two sets of conformance criteria, one for 1992 compatibility and one for 2001 compatibility. Certainly, it is understandable that interpretations of the text might differ. That is precisely why the language was altered - in the hopes that the originally intended behavior would be better understood.
 
Now if you have two implementations and the understanding of the spec on the part of the implementors differs in such a way that you end up with a behavioral incompatibility, that is a real world problem that has to be addressed. But please don't put us in the position of trying to maintain compatibility to two different spec interpretations as if the protocol was intentionally altered between 1992/2001 in an incompatible way. It wasn't.
 
More comments below.
 
  Les
 
-----Original Message-----
From: Philip Christian [mailto:christi@nortelnetworks.com]
Sent: Wednesday, February 13, 2002 1:44 PM
To: 'Les Ginsberg'; 'mike shand'; 'Dave Katz'; 'Jeff Learman'
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

Les,
 
I also just read this in 10589:2001
 
"9.7 Point-to-point IS to IS hello PDU
This PDU is transmitted by Intermediate systems on
nonbroadcast circuits, after receiving an ISH PDU from the
neighbour system."
 
This would appear to back you up, but it really is a shame that it wasn't more clearly stated.
 
I might not be very popular for saying this, but there does then appear to be a fundamental incompatibility.
 
You have one router that conforms to 10589:2001 that will not send IIH until it gets an ISH, and sits there sending out ISHs.
Then you have another that doesn't send ISHs and sits there waiting for an IIH that never comes.
[Les Ginsberg] 
Yes - this is the essence of the incompatibility - but it is NOT a 10589:2001 issue. In the IP world, some implementations simply don't send ISHs - and therefore you can get into this deadlock unless the other end is willing to start sending IIHs on receipt of an IIH even without an ISH. That is precisely the issue which we are trying to clarify with a new RFC.
 
 
 
One thing that I still don't understand is this: if a 10589:2001 implementation receives an IIH but no ISH, does it still sit there determined not to reply?
[Les Ginsberg]  Yes, a strictly conformant implementation would do that. That is true of a strictly conformant 10589 implementation regardless of spec vintage. Please do not wordsmith me here. Yes, the 1992 spec wasn't worded as well as it might be - but I think there is clear historical evidence for what was intended. 
 
It would appear that it still has to perform the IIH acceptance tests, doesn't it?
Will it actually bring up an adjacency and still not send an IIH back?
There seems to be a contradiction here.
 
We seem to have a choice here, either
 
1. Go against 10589:2001 and explicitly state that if you get an IIH then you MUST send an IIH back and perform the IIH acceptance tests (plus three way handshake if you both support). If we go against ISO and RFC 1195 (clarify ;-) ) then it needs to be very clearly stated that this is what is happening.
 
or
 
2. Say that routers MUST send and receive/process ISHs, whether or not they forward CLNP or not.
 
I think that only one of these actually guarantees interop.
[Les Ginsberg] 
No. That is NOT necessary. All that is necessary is that an implementation relax its requirements so that it will create an adjacency (in initialising state) and start sending IIHs on receipt of an IIH even in the absence of an ISH.
 
 
 
There is the third option of course, make "1" AND "2" mandatory, which upsets almost everyone but doubly guarantees interop. Now there's a thought.
[Les Ginsberg] YOu are right - such a suggestion is likely to make you very unpopular. 
 
Philip
-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: 13 February 2002 20:42
To: Christian, Philip [HAL02:GI50:EXCH]; 'mike shand'
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

The original text in 10589:1992 8.2.3 caused confusion because it said to send IIHs when "the circuit is first enabled". This suggested that there was no need to wait for receipt of an ISH. This was not the intended behavior. A Defect Report was filed in April of 1993 (JTC1/SC6/WG2/N523 - for those of you lucky enough to have a vintage copy) in which this confusion was discussed. My transcribed quote (no electronic copy I am afraid) reads:
 
"There seems to be a problem with the 10589 description of the initialization of pt-pt circuits in clause 8.2. In ISO 9542 the IS starts off by sending an ISH PDU and only when the IS has detected that the other end is an IS (by receipt of its ISH PDU) should the IS start sending IIH PDUs. In 10589 there seems to be an anomaly. 8.2.2 says what you do when you receive an ISH, but nothing tells you to send them. 8.2.3 tells you to send IIH PDUs all the time. It looks as if some attempt has been made to remove the initial ISH exchange step, but it hasn't been completed. The standard needs to specify that upon circuit initialization the IS sends an ISH PDU, and sends IIH PDUs in response to receipt of ISH PDUs."
 
With that in mind, two changes were introduced (refer to 10589:2001 draft for full text):
 
1)New section 8.2.3 was added to explicitly state that an ISH needed to be sent when a point-point circuit was first enabled. Additional wording was added to this section to clarify issues that arose in SIF a few years ago regarding whether ISHs should continue to be periodically sent after an adjacency was up.
 
2)8.2.4a (renumbered from 8.2.3.a in 1992 spec) was changed to indicate that an IIH should be sent upon receipt of an ISH rather than when the circuit is first enabled.
 
The issue that still seems to confuse some folks is 8.2.4b which says to send IIHs when the "iSISHelloTimer expires". What is not explicity stated (but sort of naturally falls out when you implement it (he said foolishly)) is that you don't start running the "iSISHelloTimer" until you send your first IIH - which would come AFTER receiving an ISH. It might have been clearer if some statement were explicutly made to say that the timer is not started when the circuit is enabled - but I believe that was what is meant both by the current and the original text.
 
I hope this at least clarifies the points raised below.
 
 
   Les
 
-----Original Message-----
From: Philip Christian [mailto:christi@nortelnetworks.com]
Sent: Wednesday, February 13, 2002 7:05 AM
To: 'mike shand'
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

From ISO/IEC 10589:1992 8.2.3
"8.2.3 Sending point-to-point IIH PDUs
An IS shall send PointtoPoint IIH PDUs on those PointtoPoint circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the circuit is first enabled; or
b) whenever iSISHelloTimer expires"
 
In ISO/IEC 10589:2001 8.2.4 this becomes
"8.2.4 Sending point-to-point IIH PDUs
An IS shall send Point-to-Point IIH PDUs on those Point-to-Point circuits whose externalDomain attribute is set "False".
The IIH PDU shall be sent when:
a) the IS receives an ISH PDU
b) whenever iSISHelloTimer expires"
 
So, in neither case do the standards behave as per the original idea, because you do send an IIH whenever the timer expires, whether you have received an ISH or not, and so you will send IIHs to an OSI End System.
 
One interesting difference between the two is that under 1992 rules you sent an IIH when the circuit is enabled, which would result in an adjacency coming up immediately with or without ISHs, whereas, with the 2001 rules, if you don't listen to ISHs then you might have to wait an entire iSISHelloTimer interval before you see the other end.
 
At least that is my enterpretation of it.
 
I'd love to know the reasoning behind the change.
 
Philip
 
 
 
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: 13 February 2002 13:22
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

At 13:15 13/02/2002 +0000, Philip Christian wrote:
So that explains why an OSI router needs to send ISH, as there might be an ES that needs it.
It doesn't explain why an OSI router needs to process incoming ISH though. Why is that in the standard?

Well the ORIGINAL idea was that an ES might get upset if it started getting IIHs sent to it. So we only sent IIHs after we had established that the neighbor was indeed a router (by receiving an ISH).

But that really doesn't apply any more, even if it ever did.

        Mike


------_=_NextPart_001_01C1B4DE.5C9543B0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 17:57:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23547 for ; Wed, 13 Feb 2002 17:57:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DMn1L07987; Wed, 13 Feb 2002 14:49:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DMm4L07975 for ; Wed, 13 Feb 2002 14:48:04 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp161.cisco.com [10.50.0.160]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA00764; Wed, 13 Feb 2002 22:54:00 GMT Message-Id: <4.3.2.7.2.20020213224942.03297268@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: mike shand Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 22:53:33 +0000 There seems to be something funny happening with the list. I sent this reply nearly 6 hours ago, and I still haven't seen it on the list. I'm sending again in case that helps, but I apologize in advance if this results in a double posting when the original eventually arrives. In any case Les appears to have said all I wanted to say anyway (and rather better:-). Mike At 15:05 13/02/2002 +0000, Philip Christian wrote: >I'd love to know the reasoning behind the change. My guess is that there wasn't any reasoning at all, but that it happened as an accident, when the full description of the use of ISHs was removed and replaced by the second para in 8.2 which says The IS shall operate the ISO 9542 protocol, shall be able to receive ISO 9542 ISH PDUs from other ISs and shall store the information so obtained in the adjacency database. Probably the intention was that this included the sending of the initial ISH, but the words at the beginning of 8.2.3 were fumbled so that it got contradicted. Note that there is a vestige of the original behaviour in bulllet (c) of that para which says The first pt-pt ISH PDU (i.e. that transmitted as a result of receiving an ISH PDU,....) However, I guess it says what it says, and we have to cut our cloth accordingly. Mike historical note:- the words at the start of 8.2 were inserted when the original DECnet spec was ISO'ised. It used to say When a pt-pt router to router hello is required to be transmitted as described in previous sections, it is constructed as follows... and then proceeds with a) the circuit type field shall be set... etc. and of course the "previous sections" described sending an IIH only after receiving an ISH. But this is all history now. :-) _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 18:24:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24057 for ; Wed, 13 Feb 2002 18:24:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DNF1L08130; Wed, 13 Feb 2002 15:15:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DNEBL08115 for ; Wed, 13 Feb 2002 15:14:11 -0800 (PST) (envelope-from mbartell@cisco.com) Received: from MBARTELL-W2K.cisco.com (mbartell-w2k.cisco.com [64.101.142.68]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA01266; Wed, 13 Feb 2002 15:20:04 -0800 (PST) Message-Id: <4.3.2.7.2.20020213170611.01741380@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Learman From: Micah Bartell Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: isis-wg@spider.juniper.net In-Reply-To: <4.3.2.7.2.20020213154656.01d18fe0@dingdong.cisco.com> References: <4.3.2.7.2.20020213142634.016e9318@cactus.cisco.com> <4103264BC8D3D51180B7002048400C450714FF@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 17:20:04 -0600 Folks, Alright, I think we are almost in agreement now....any further thoughts? I took advantage of this draft to point out that 10589 does allow an IIH to be sent in response to an IIH even without an ISH, as it is a bit hidden in section 8.2.5.2 in the state tables. I also made the point that if CLNS ES attachment is supported by the IS over p-t-p circuits, they must continue to conform to 8.2.3 ( 10589/TC1 ). /mpb IS-IS Adjacency Establishment in IP Only Environments 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes a modification to the IS-IS protocol in IP Only environments for adjacency establishment over Point to Point circuits. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [1]. This draft describes a modification to the IS-IS protocol, which will allow an IS-IS adjacency to be established over Point to Point circuits without the use of an Intermediate System Hello PDU (ISH). 3. The History of the ISH The IS-IS protocol as defined in [2] was intended for use with the Connectionless Network Service (CLNS). The extensible nature of IS-IS enabled IS-IS to be extended to provide multiprotocol support in an integrated routing protocol, Integrated IS-IS, as defined in [1]. Integrated IS-IS now supports reachability information for CLNS, IPv4, and IPv6. The original intent of [1] was to provide a routing protocol capable of handling both CLNS and IPv4 reachability information. To support the possibility of a CLNS ES attached on a point to point link, ISs are required to send ISH PDUs, and are not to send IIH PDUs before receiving an ISH from the peer. For this reason section 5.1 [1] states: "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links." Section 5.1 [1] re-enforces the need to comply with section 8.2.4 [3]. However, in an IP Only environment, there is no need to issue an ISH PDU over a Point to Point circuit because there are no End Systems with which to form an ES-IS adjacency. 4. Best Common Practice An IP Only implementation has no need to issue an ISH PDU as described in section 8.2.4 of [3]. An IP Only implementation MAY issue an IIH PDU when a Point to Point circuit transitions into an "Up" state to initiate the formation of an IS-IS adjacency. The IIH PDU SHOULD still be issued in conformance with section 8.2.4 [3] with the exception of the requirement for reception of an ISH PDU. An IIH PDU MAY be issued in response to the receipt of an IIH PDU in accordance with section 8.2.5.2 [3]. A multiprotocol IS that supports the attachment of CLNS ESs over Point to Point circuits MUST act in accordance with section 8.2.2 [3] when CLNS functionality is enabled. 5. Security Considerations This document raises no new security issues for IS-IS. 6. References [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments" RFC 1195, December 1990 [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992 [3] ISO, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473) Technical Corrigendum 1", ISO/IEC 10589:1992 TC1, May 1993. >Not quite. You don't send an ISH to detect an ES. You send an ISH so >that the ES knows you're a router (if it is an ES) and the *ES* forms >an ES-IS adjacency. I would revise this to say, > > To support the possibility of a CLNS ES attached on a PTP link, > ISs are required to send ISH PDUs, and are not to send IIH PDUs > before receiving an ISH from the peer. > > > For this reason section 5.1 of [1] states: > > > > "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate > > system Hellos) is used to initialize the link, and to allow each > > router to know if there is a router on the other end of the link, > > before IS-IS Hellos are exchanged. All routers implementing IS-IS > > (whether IP-only, OSI-only, or dual), if they have any interfaces on > > point-to-point links, must therefore be able to transmit ISO 9542 > > ISHs on their point-to-point links." > > > > Section 5.1 of [1] re-enforces the need to comply with section 8.2.4 > > of [2]. > >See note below about TC1. > > >This requirement was defined when the industry mindset was > > that of dual environments being the general case. The general case > > has instead shifted to IP Only environments. > >I don't think we need to talk about mindset, and there are members of >this list who consider dual environments very important. All you need >is to begin the next sentence with "However,". > > > In an IP Only environment, there is no need to issue an ISH PDU over a > > Point to Point circuit because there are no End Systems with which to > > form an ES-IS adjacency. > > > >[2] requires that an ISH be received in order > > to issue an IIH PDU. > >This is inaccurate unless you specify [2] as including TC1. >10589:1992 says, in 8.2.3 (renumbered by TC1 as 8.2.4) > > The IIH PDU shall be sent when: a) the circuit is first enabled. > >It would be more accurate to say that [2] allows sending the IIH first, but >this was a mistake that was corrected in [3], and is now being allowed >again in certain circumstances. > >[3] ISO, "Intermediate System to Intermediate System Intra- > Domain Routeing Exchange Protocol for use in Conjunction with the > Protocol for Providing the Connectionless-mode Network Service (ISO > 8473) Technical Corrigendum 1", ISO/IEC 10589:1992 TC1, May 1993. > >Plus, you would need to change [2] in text below to [3]. > > >4. Best Common Practice > > > > An IP Only implementation has no need to issue an ISH PDU as described in > > section 8.2.4 of [2]. An IP Only implementation MAY issue an IIH PDU > > when a Point to Point circuit transitions into an "Up" state to > > initiate the formation of an IS-IS adjacency. An IP Only implementation > > SHOULD accept an IIH to initialize an adjacency regardless of an ISH > > having been issued. The IIH PDU SHOULD still be issued in conformance > > with section 8.2.4 of [2] with the exception of the requirement for > > reception of an ISH PDU. > > > > An implementation that supports the forwarding of CLNS PDU's MUST act in > > full accordance with section 8.2.4 of [2] when CLNS functionality is > > enabled, including the initial issuance of an ISH PDU. > >An implementation that supports CLNP should be allowed to send an IIH >after receiving one, but this is not permitted by [3]. After receiving >the IIH, we know that the neighbor is clearly an IS, so there is no >need to wait for an ESH or ISH. > >I would say: > > An implementation that does not support attachments to CLNP End > Systems via PTP links MAY send an IIH without waiting for an ISH, > and MAY omit sending an ISH. > > An implementation that does support attachments to CLNP End > Systems via PTP links MUST send an ISH when a PTP circuit is > established, and MAY send an IIH after receiving an IIH on the > link. > > >5. Security Considerations > > > > This document raises no new security issues for IS-IS. > > > >6. References > > > > [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual > > Environments" RFC 1195, December 1990 > > > > [2] ISO, "Intermediate System to Intermediate System Intra- > > Domain Routeing Exchange Protocol for use in Conjunction with the > > Protocol for Providing the Connectionless-mode Network Service (ISO > > 8473)", ISO/IEC 10589:1992 > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 18:37:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24249 for ; Wed, 13 Feb 2002 18:37:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DNU7L08257; Wed, 13 Feb 2002 15:30:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g15LcTL52063 for ; Tue, 5 Feb 2002 13:38:29 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g15Lhec17655 for ; Tue, 5 Feb 2002 13:43:41 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Feb 2002 13:40:04 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20500; Tue, 5 Feb 2002 16:40:41 -0500 (EST) Message-Id: <200202052140.QAA20500@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , isis-wg@juniper.net From: The IESG X-OriginalArrivalTime: 05 Feb 2002 21:40:04.0483 (UTC) FILETIME=[AC254530:01C1AE8D] Subject: [Isis-wg] Document Action: IS-IS Transient Blackhole Avoidance to Informational Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 05 Feb 2002 16:40:40 -0500 The IESG has approved the Internet-Draft 'IS-IS Transient Blackhole Avoidance' as an Informational RFC. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Bill Fenner and Randy Bush. Note to the RFC Editor: draft-ietf-isis-transient-02.txt is encoded with the MIME Quoted-Printable content encoding. In addition, the I-D uses hyphenation to break words across lines. If these issues cause problems while preparing the document for publication, we can arrange for a new I-D from the author with these issues solved. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 18:44:36 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24333 for ; Wed, 13 Feb 2002 18:44:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DNb1L08492; Wed, 13 Feb 2002 15:37:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DNa5L08480 for ; Wed, 13 Feb 2002 15:36:05 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1DNgNn19130 for ; Wed, 13 Feb 2002 18:42:23 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAT47801; Wed, 13 Feb 2002 18:42:04 -0500 (EST) Message-Id: <4.3.2.7.2.20020213183457.03cce130@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@spider.juniper.net From: Jeff Learman Subject: Fwd: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 18:41:58 -0500 Well, once again I get to eat some humble pie. Recently someone convinced me that an IS was not supposed to send an IIH on receipt of an IIH, based on the text in 10589:1992 8.2.3 (2001 section 8.2.4), which says An IS shall send PTP IIH PDUs on those PTP circuits whose externalDomain attribute is set "False". The IIH PDU shall be sent when: a) the circuit is first enabled [TC1 & 2001: the is receives an ISH] b) whenever iSISHelloTimer expires It would have been helpful if this had also said: c) on receipt of an IIH pdu, in accordance with 8.2.4.2 [8.2.5.2] Anyway, I've been on a wild tangent. There should NOT be an interoperability problem between systems that don't send ISHs and those that follow 10598 explicitly (any version), because on receipt of the IIH, the receiving system is required to respond with an IIH. Thanks to Micah who cleared this up for me. Regards, Jeff >Date: Wed, 13 Feb 2002 16:14:23 -0500 >To: Micah Bartell >From: Jeff Learman >Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH >Cc: isis-wg@spider.juniper.net > >At 03:34 PM 2/13/2002, Micah Bartell wrote: >>Alright....I went back and did a rehash of your doco and mine. Integrated parts and made sure I got Dave's last comments addressed. >> >>At this point 10589:2001 is not a formal IS, so I would rather just reference 10589:1992 and RFC 1195. >> >>I would rather see a quick synopsis of what is required to be compliant than an explanation of the various implementations. If you follow the BP for IIH and ISH handling, you will be compliant with all of the implementations. >> >>I think the point here is to identify where the issue is, RFC 1195 section 5.1 and 10589 Section 8.2.4. Why it says what it does, when we do not need to strictly adhere, and in what manner we do not need to adhere. >> >>/mpb >> >> >> >> IS-IS Adjacency Establishment in IP Only Environments >> >> >> >>1. Status of this Document >> >> This document is an Internet-Draft and is in full conformance with all >> provisions of Section 10 of RFC2026. >> >> Internet-Drafts are working documents of the Internet Engineering Task >> Force (IETF), its areas, and its working groups. Note that other groups >> may also distribute working documents as Internet-Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsolete by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference material >> or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >>2. Abstract >> >> This document describes a modification to the IS-IS protocol in IP Only >> environments for adjacency establishment over Point to Point circuits. >> The IS-IS protocol is specified in [2], with extensions for supporting >> IPv4 specified in [1]. >> >> This draft describes a modification to the IS-IS protocol, which will >> allow an IS-IS adjacency to be established over Point to Point circuits >> without the use of an Intermediate System Hello PDU (ISH). >> >>3. Introduction >> >> The IS-IS protocol as defined in [2] was intended for use with the >> Connectionless Network Service (CLNS). The extensible nature of IS-IS >> enabled IS-IS to be extended to provide multiprotocol support in an >> integrated routing protocol, Integrated IS-IS, as defined in [1]. >> Integrated IS-IS now supports reachability information for CLNS, IPv4, >> and IPv6. >> >> The original intent of [1] was to provide a routing protocol capable >> of handling both CLNS and IPv4 reachability information. > > > >> The need to >> support CLNS reachability information required that an ISH be issued >> to detect End Systems (ES) and initiate the formation of an ES-IS >> adjacency. > >Not quite. You don't send an ISH to detect an ES. You send an ISH so >that the ES knows you're a router (if it is an ES) and the *ES* forms >an ES-IS adjacency. I would revise this to say, > > To support the possibility of a CLNS ES attached on a PTP link, > ISs are required to send ISH PDUs, and are not to send IIH PDUs > before receiving an ISH from the peer. > >> For this reason section 5.1 of [1] states: >> >> "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate >> system Hellos) is used to initialize the link, and to allow each >> router to know if there is a router on the other end of the link, >> before IS-IS Hellos are exchanged. All routers implementing IS-IS >> (whether IP-only, OSI-only, or dual), if they have any interfaces on >> point-to-point links, must therefore be able to transmit ISO 9542 >> ISHs on their point-to-point links." >> >> Section 5.1 of [1] re-enforces the need to comply with section 8.2.4 >> of [2]. > >See note below about TC1. > >>This requirement was defined when the industry mindset was >> that of dual environments being the general case. The general case >> has instead shifted to IP Only environments. > >I don't think we need to talk about mindset, and there are members of >this list who consider dual environments very important. All you need >is to begin the next sentence with "However,". > >> In an IP Only environment, there is no need to issue an ISH PDU over a >> Point to Point circuit because there are no End Systems with which to >> form an ES-IS adjacency. > > >>[2] requires that an ISH be received in order >> to issue an IIH PDU. > >This is inaccurate unless you specify [2] as including TC1. >10589:1992 says, in 8.2.3 (renumbered by TC1 as 8.2.4) > > The IIH PDU shall be sent when: a) the circuit is first enabled. > >It would be more accurate to say that [2] allows sending the IIH first, but >this was a mistake that was corrected in [3], and is now being allowed >again in certain circumstances. > >[3] ISO, "Intermediate System to Intermediate System Intra- > Domain Routeing Exchange Protocol for use in Conjunction with the > Protocol for Providing the Connectionless-mode Network Service (ISO > 8473) Technical Corrigendum 1", ISO/IEC 10589:1992 TC1, May 1993. > >Plus, you would need to change [2] in text below to [3]. > >>4. Best Common Practice >> >> An IP Only implementation has no need to issue an ISH PDU as described in >> section 8.2.4 of [2]. An IP Only implementation MAY issue an IIH PDU >> when a Point to Point circuit transitions into an "Up" state to >> initiate the formation of an IS-IS adjacency. An IP Only implementation >> SHOULD accept an IIH to initialize an adjacency regardless of an ISH >> having been issued. The IIH PDU SHOULD still be issued in conformance >> with section 8.2.4 of [2] with the exception of the requirement for >> reception of an ISH PDU. >> >> An implementation that supports the forwarding of CLNS PDU's MUST act in >> full accordance with section 8.2.4 of [2] when CLNS functionality is >> enabled, including the initial issuance of an ISH PDU. > >An implementation that supports CLNP should be allowed to send an IIH >after receiving one, but this is not permitted by [3]. After receiving >the IIH, we know that the neighbor is clearly an IS, so there is no >need to wait for an ESH or ISH. > >I would say: > > An implementation that does not support attachments to CLNP End > Systems via PTP links MAY send an IIH without waiting for an ISH, > and MAY omit sending an ISH. > > An implementation that does support attachments to CLNP End > Systems via PTP links MUST send an ISH when a PTP circuit is > established, and MAY send an IIH after receiving an IIH on the > link. > >>5. Security Considerations >> >> This document raises no new security issues for IS-IS. >> >>6. References >> >> [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual >> Environments" RFC 1195, December 1990 >> >> [2] ISO, "Intermediate System to Intermediate System Intra- >> Domain Routeing Exchange Protocol for use in Conjunction with the >> Protocol for Providing the Connectionless-mode Network Service (ISO >> 8473)", ISO/IEC 10589:1992 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 18:59:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24503 for ; Wed, 13 Feb 2002 18:58:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DNp1L08602; Wed, 13 Feb 2002 15:51:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DNo9L08590 for ; Wed, 13 Feb 2002 15:50:09 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Micah Bartell'" , Jeff Learman Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 18:55:53 -0500 Good start. Some suggestions below. > > IS-IS Adjacency Establishment in IP Only Environments > > The original intent of [1] was to provide a routing > protocol capable of handling both CLNS and IPv4 reachability > information. "Original Intent" suggests that the reference will be 10589 or some earlier DECNet document. Perhaps "The changes to 10589 [3] that were proposed in RFC 1195 [1] were designed to provide....." > To support > the possibility of a CLNS ES attached on a point to point > link, ISs > are required to send ISH PDUs, and are not to send IIH PDUs before > receiving an ISH from the peer. Perhaps this would flow more naturally if you started with the ISO host/client protocol. Second, I don't think this was special to p2p - I think ISO had the same behavior on LANs. > 4. Best Common Practice > > An IP Only implementation has no need to issue an ISH PDU > as described in > section 8.2.4 of [3]. An IP Only implementation MAY > issue an IIH PDU > when a Point to Point circuit transitions into an "Up" > state to initiate > the formation of an IS-IS adjacency. Do you need to qualify this? Why not just say that an IP Only implementation MAY send an IIH whenever it is enabled on a link. I think trying to overspecify may have created the problem we see. I'd suggest these items be bullets as well. > The IIH PDU SHOULD still be issued > in conformance with section 8.2.4 [3] with the exception of the > requirement for reception of an ISH PDU. Should we spell out what 8.2.4 says? > An IIH PDU MAY > be issued in > response to the receipt of an IIH PDU in accordance with section > 8.2.5.2 [3]. > A multiprotocol IS that supports the attachment of CLNS > ESs over Point > to Point circuits MUST act in accordance with section > 8.2.2 [3] when > CLNS functionality is enabled. Perhaps you just want to say that it "A multiprotocol IS that supports the attachment of CLNS ESs MUST generaate ISH hellos in accordance with section 8.2.2 [3] ..." - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 19:26:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24818 for ; Wed, 13 Feb 2002 19:26:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E0I1L08763; Wed, 13 Feb 2002 16:18:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E0HrL08751 for ; Wed, 13 Feb 2002 16:17:53 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1E0OBT21842; Wed, 13 Feb 2002 19:24:11 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAT48730; Wed, 13 Feb 2002 19:23:53 -0500 (EST) Message-Id: <4.3.2.7.2.20020213192122.03c79eb8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Jeff Learman Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: "'Micah Bartell'" , isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 19:23:51 -0500 >> To support >> the possibility of a CLNS ES attached on a point to point >> link, ISs >> are required to send ISH PDUs, and are not to send IIH PDUs before >> receiving an ISH from the peer. > >Perhaps this would flow more naturally if you started with the >ISO host/client protocol. Second, I don't think this was special to >p2p - I think ISO had the same behavior on LANs. Not exactly, LANs are different. You send an ISH in order to support ESs, but you don't wait to get an ISH before sending an IIH because it's sent to the ISIS multicast address. Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 19:31:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24887 for ; Wed, 13 Feb 2002 19:31:36 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E0O1L08820; Wed, 13 Feb 2002 16:24:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E0NKL08808 for ; Wed, 13 Feb 2002 16:23:20 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Jeff Learman'" , Jeff Parker Cc: "'Micah Bartell'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 19:29:05 -0500 > >> To support > >> the possibility of a CLNS ES attached on a point to point > >> link, ISs > >> are required to send ISH PDUs, and are not to send IIH > PDUs before > >> receiving an ISH from the peer. > > > >Perhaps this would flow more naturally if you started with the > >ISO host/client protocol. Second, I don't think this was special to > >p2p - I think ISO had the same behavior on LANs. > > Not exactly, LANs are different. You send an ISH in order to > support ESs, > but you don't wait to get an ISH before sending an IIH because it's > sent to the ISIS multicast address. > > Jeff Jeff - I'm just suggesting that Micah's text reads more clearly without the qualification to P2P. For example: "IS-IS Routers send ISH Hellos to allow Endstations to locate routers." That is why they do it. Then he can go on to suggest that they need not wait to send out an IIH on P2P. We may want to reference the Finite State Machines and the prose, but right now he is trying to describe why these things exist. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 19:56:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25102 for ; Wed, 13 Feb 2002 19:56:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E0n1L08970; Wed, 13 Feb 2002 16:49:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E0mpL08958 for ; Wed, 13 Feb 2002 16:48:51 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA16157; Wed, 13 Feb 2002 16:54:47 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 16:54:47 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F7C9@avalon.pluris.com> From: Les Ginsberg To: "'Micah Bartell'" , Jeff Learman Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 16:54:47 -0800 > > > Folks, > > Alright, I think we are almost in agreement now....any > further thoughts? I > took advantage of this draft to point out that 10589 does > allow an IIH to > be sent in response to an IIH even without an ISH, as it is a > bit hidden in > section 8.2.5.2 in the state tables. I also made the point > that if CLNS ES > attachment is supported by the IS over p-t-p circuits, they > must continue > to conform to 8.2.3 ( 10589/TC1 ). > > /mpb > Well, that's an interesting find - and yet another point of confusion since there is no place in 10589 that specifies CREATING an adjacency as a result of receiving an IIH, which would seem to be necessary to determine what the "neighbourSystemType" is. And clearly, if we are supposed to send IIHs in response to receiving one(in some situations), then some such verbiage should have been added to 8.2.4. My preference is to not try to use 8.2.5.2 as a reference here since there is ambiguity. (In any case it is actually the state tables that specify sending the IIH, not the text body). Let's just admit that the problem comes about because some implementations require an ISH to be received before creating an adjacency and since some IP only implementations don't send ISHs we need to specify that an adjacency can be created as a result of receiving an IIH and we can then initiate sending IIHs if we have not already. I will try to wordsmith this when I have more time - unless somebody beats me to it. Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 13 22:48:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29730 for ; Wed, 13 Feb 2002 22:48:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E3d1L09648; Wed, 13 Feb 2002 19:39:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E3cNL09636 for ; Wed, 13 Feb 2002 19:38:23 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.115] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id TAA22918; Wed, 13 Feb 2002 19:42:33 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <38112862908.20020213194353@nexsi.com> To: "Amir Hermelin" CC: "ISIS-wg (E-mail)" Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 19:43:53 -0800 Content-Transfer-Encoding: 7bit Amir, > Alex, > thanks for your comments. > As I recall from the last meeting, the "agreement" that only mode 2 is needed > was only stated by three or four people, and objected by one or two (myself > included) - hardly a consensus. You're probably right. > Some folks also approached me after the meeting and stated that mode 1 is useful. > The important part is this: the draft permits implementation of only mode 2, so > mode 1 is optional (as is the whole draft). I'm trying to understand the scenarios where mode 1 would really be useful... I tend to think (though I might be wrong, and if so, please correct me) that reachability information is probably not the major contributing factor (since ISP folks use IGPs to "glue loopbacks together" and use BGP to distribute the actual routes) and hence off-loading it to extended LSPs would not free much space in the standard LSPs. If this is the TE scenario, then most probably most if not all routers in the network would experience the problem and a) all of them would need to be SW-upgraded with either mode, and b) we can't put much more topological info in the LSPs since we still have the same limitation for it. Could you (or anyone who cares) please shed some light on why you think mode 1 is useful. Not trying to say it is necessarily not useful, just trying to understand the motivation... > You don't need extra code, knobs, bugs, etc if your customers don't want > this. And since the text is already written, I don't see a good argument > for removing it (the text). Of course, whether or not both modes are > implemented doesn't affect people who'll want to transition to mode 2 eventually. > Does that sound good to you? Any thoughts from the group on this? It is surely fine with me if mode 1 happens to add real value. If not, I guess the argument "it's already written" does not strike me as very persuasive technically ;) Regards, Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 02:01:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06656 for ; Thu, 14 Feb 2002 02:01:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E6r1L10450; Wed, 13 Feb 2002 22:53:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1E6qoL10438 for ; Wed, 13 Feb 2002 22:52:51 -0800 (PST) (envelope-from koen.vermeulen@alcatel.be) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g1E6wjn26294; Thu, 14 Feb 2002 07:58:46 +0100 (MET) Message-ID: <3C6B601C.F6A67526@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: Isis-wg Subject: Re: [Isis-wg] Regarding draft-ietf-isis-wg-mib-07.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 07:58:36 +0100 Content-Transfer-Encoding: 7bit Hello Jeff, Don't we also need an 'extended local circuit id' (used for creating point-to-point '3-way handshake' ajacencies) for point-to-point circuits? Koen Jeff Parker wrote: > > [ We should have a ] > > separate 'isisCircLocalId' per level > > > Koen > > Koen - > I think you are right. I have just made > the change. Look for it when .08 arrives. > > - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 05:44:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14897 for ; Thu, 14 Feb 2002 05:44:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EAa1L11345; Thu, 14 Feb 2002 02:36:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EAZlL11333 for ; Thu, 14 Feb 2002 02:35:47 -0800 (PST) (envelope-from matthew.noble@riverstonenet.com) Received: from ssntw1 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA22172; Thu, 14 Feb 2002 02:41:42 -0800 (PST) From: "Matthew Noble" To: "Mike Shand (E-mail)" Cc: "'Isis-Wg (E-mail)" Message-ID: <000001c1b544$948285b0$71d814ac@ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Isis-wg] Format of Restart TLV Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 10:43:47 -0000 Content-Transfer-Encoding: 7bit Mike From your ISIS Restart draft, when a "helper" node responds to a Restart TLV from a "restarter" node, it returns the RA bit set and the remaining time of the adjacency holding time. This as it is is fine for p2p, but on a LAN where there could be mutiple "restarter" nodes on the LAN, the info in the broadcast IIH is specific to one "restarter" but will be received and prcossed equally by all "restarter" nodes on that LAN. Should the remaining holding time in the restart TLV be qualified by the sysid of the "restarter" to which it refers ? Omission of this qualification means that all the "restarter" nodes on the LAN will use the minimum value of the remaining holding times sent out by the "helper" nodes. This is not a disaster but reduces further the chances that the "restarter" nodes will complete the restart process, and so increase the possibility of churn in the routing tables. What do you think ? Thanks Matt _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 06:25:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15205 for ; Thu, 14 Feb 2002 06:25:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EBI2L12054; Thu, 14 Feb 2002 03:18:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EBHPL12042 for ; Thu, 14 Feb 2002 03:17:26 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EBNSt10007 for ; Thu, 14 Feb 2002 06:23:28 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EBNPP23361 for ; Thu, 14 Feb 2002 12:23:25 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EBN1M28847 for ; Thu, 14 Feb 2002 11:23:01 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS709NV>; Thu, 14 Feb 2002 11:23:26 -0000 Message-ID: <4103264BC8D3D51180B7002048400C45071506@zhard0jd.europe.nortel.com> From: "Philip Christian" To: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B54A.034B2BF0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 11:23:23 -0000 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_01C1B54A.034B2BF0 Content-Type: text/plain; charset="iso-8859-1" My text has come out a little differently to Micah's. The main difference is that it acknowledges the existance of implementations that will not form an adjacency unless they receive an ISH. One can argue whether such behaviour is right or wrong, but that would be missing the point. From e-mails that I have had, it would appear that such implementations are "out there", and this text deals with it. However, I have not had any hard evidence that such an implementation has been deployed, only e-mails saying that it is valid to do it that way (which would suggest that folks have deployed it). If in fact no one has deployed an IP-capable router that behaves that way, then there is no point in specifying how to interwork with it, and my text would them become very similar to Micah's. An e-mail from someone saying "yes, I have seen that in the field" would be nice. It would certainly appear that implementations are "out there" that do not sent ISHs. I believe that it does not matter how OSI-only implementations might act (read SONET/SDH ADMs), as anything that can forward CLNP (dual or OSI-only) will naturally send ISHs anyway. However if one is going to upgrade a SONET/SDH ADM to make it dual, then one had better make sure that IIHs with no ISHs will bring up the adjacency. The aim of this doc to provide information to those who want to interop with everything that exists, not to say who is wrong or right. I hope that this helps. Philip Use of IS-IS ISH PDUs in IP Only Environments 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This document describes how ISH PDUs are commonly used within the IS-IS protocol in IP Only environments for adjacency establishment over Point to Point circuits. This document suggests best practise to guarantee interoperability with all deployed implementations. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [1]. 3. The History of the ISH PDU The IS-IS protocol as defined in [2] is intended for use with the Connectionless Network Service (CLNS). Due to the extensible nature of IS-IS it was possible to extend IS-IS to provide an integrated routing protocol which is Integrated IS-IS as defined in [1]. Integrated IS-IS may now be used to route CLNP, IPv4 and IPv6 packets. As the original intent of RFC 1195[1] was to provide a routing protocol capable of routing both CLNP and IPv4 packets, all of the requirements of [2] had to be retained. This included the use of ISH PDUs, which are needed to connect an OSI End System (ES) to an IS-IS router. An ES is the OSI equivalent to an IP host. Thus RFC 1195 [1] states in section 5.1:- "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links." With time IP become the protocol of the Internet, and routers that could forward CLNP packets became increasingly rare. The majority of Integrated IS-IS routers were IP-only and thus incapable of forwarding traffic to OSI ESs. For many years there have been different opinions on what the exact purpose of ISH PDUs. One opinion is that ISH PDUs are there purely for connection to OSI ESs. Taken to its logical conclusion, this results an implementations that do not support forwarding of CLNP packets not sending ISH PDUs either. An alternative opinion is that ISH PDUs are an integral part of the IS-IS router to router adjacency formation process. This approach is reflected in later versions of ISO/IEC 10589. Taken to its logical conclusion this results in implementations that will not form an adjacency unless an ISH is received. The unfortunate outcome is the possibility of one implementation that does not send ISH PDUs over a point-to-point link becoming connected to an alternative implementation that will not form an adjacency unless it receives an ISH. 4. Deployed IS-IS and best practice Given that later versions of ISO/IEC 10589 have been enterpreted as stating that no adjacency will be formed until an ISH is received, the only way to initiate an adjacency with a resultant implementation is to actually send an ISH. Therefore if interoperability is wanted with such implementations, then an IS-IS router SHOULD send an ISH PDUs over a point-to-point circuit whenever the circuit is first enabled, and periodically whenever a circuit is Down, whether or not the router can forward CLNP packets. Given that earlier versions of ISO/IEC 10589 have been enterpreted as stating that ISH PDUs are not required if CLNP forwarding is not supported, then the only way to initiate an adjacency with a resultant implementation is to accept IIH PDUs in lieu of ISH PDUs. Therefore if interoperability is wanted with such implementations, then an IS-IS router SHOULD create an adjacency with adjacencyState "Initialising" and send a point-to-point IIH PDU if it receives an IIH PDU and no adjacency already exists. 5. Security Considerations This document raises no new security issues for IS-IS. 6. References [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments" RFC 1195, December 1990 [2] ISO, "Intermediate System to Intermediate System Intra- Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:1992 ------_=_NextPart_001_01C1B54A.034B2BF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Question on the usage of ISH and P2PIIH

My text has come out a little differently to = Micah's.

The main difference is that it acknowledges the = existance of implementations that will not form an adjacency unless = they receive an ISH.  One can argue whether such behaviour is = right or wrong, but that would be missing the point.  From e-mails = that I have had, it would appear that such implementations are = "out there", and this text deals with it.

However, I have not had any hard evidence that such = an implementation has been deployed, only e-mails saying that it is = valid to do it that way (which would suggest that folks have deployed = it).  If in fact no one has deployed an IP-capable router that = behaves that way, then there is no point in specifying how to interwork = with it, and my text would them become very similar to Micah's. An = e-mail from someone saying "yes, I have seen that in the = field" would be nice.

It would certainly appear that implementations are = "out there" that do not sent ISHs.

I believe that it does not matter how OSI-only = implementations might act (read SONET/SDH ADMs), as anything that can = forward CLNP (dual or OSI-only) will naturally send ISHs anyway.  = However if one is going to upgrade a SONET/SDH ADM to make it dual, = then one had better make sure that IIHs with no ISHs will bring up the = adjacency.

The aim of this doc to provide information to those = who want to interop with everything that exists, not to say who is = wrong or right.

I hope that this helps.

Philip



          &nb= sp;   Use of IS-IS ISH PDUs in IP Only Environments
          &nb= sp;           = <draft-ietf-isis-ish-00.txt>


1. Status of this Document

    This document is an Internet-Draft = and is in full conformance with
    all provisions of Section 10 of = RFC2026.

    Internet-Drafts are working = documents of the Internet Engineering Task
    Force (IETF), its areas, and its = working groups. Note that other groups
    may also distribute working = documents as Internet-Drafts.

    Internet-Drafts are draft = documents valid for a maximum of six months
    and may be updated, replaced, or = obsolete by other documents at any
    time. It is inappropriate to use = Internet-Drafts as reference material
    or to cite them other than as = "work in progress."

    The list of current = Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow = Directories can be accessed at
    http://www.ietf.org/shadow.html.

2. Abstract

    This document describes how ISH = PDUs are commonly used within the IS-IS
    protocol in IP Only environments = for adjacency establishment over Point
    to Point circuits.

    This document suggests best = practise to guarantee interoperability
    with all deployed = implementations.
  
    The IS-IS protocol is specified = in [2], with extensions for supporting
    IPv4 specified in [1].

3. The History of the ISH PDU

    The IS-IS protocol as defined in = [2] is intended for use with the
    Connectionless Network Service = (CLNS).  Due to the extensible nature of IS-IS
    it was possible to extend IS-IS = to provide an integrated routing protocol
    which is Integrated IS-IS as = defined in [1].  Integrated IS-IS may now be used
    to route CLNP, IPv4 and IPv6 = packets.

    As the original intent of RFC = 1195[1] was to provide a routing protocol
    capable of routing both CLNP and = IPv4 packets, all of the requirements of [2]
    had to be retained.  This = included the use of ISH PDUs, which are needed to
    connect an OSI End System (ES) to = an IS-IS router.  An ES is the OSI
    equivalent to an IP host.

    Thus RFC 1195 [1] states in = section 5.1:-

      "On = point-to-point links, the exchange of ISO 9542 ISHs = (intermediate
      system Hellos) is = used to initialize the link, and to allow each
      router to know if = there is a router on the other end of the link,
      before IS-IS Hellos = are exchanged. All routers implementing IS-IS
      (whether IP-only, = OSI-only, or dual), if they have any interfaces on
      point-to-point links, = must therefore be able to transmit ISO 9542
      ISHs on their = point-to-point links."

    With time IP become the protocol = of the Internet, and routers that could
    forward CLNP packets became = increasingly rare.  The majority of Integrated
    IS-IS routers were IP-only and = thus incapable of forwarding traffic to OSI
    ESs.

    For many years there have been = different opinions on what the exact purpose of
    ISH PDUs.

    One opinion is that ISH PDUs are = there purely for connection to OSI ESs.
    Taken to its logical conclusion, = this results an implementations that do not
    support forwarding of CLNP = packets not sending ISH PDUs either.

    An alternative opinion is that ISH = PDUs are an integral part of the IS-IS
    router to router adjacency = formation process.  This approach is reflected in
    later versions of ISO/IEC = 10589.  Taken to its logical conclusion this results
    in implementations that will not = form an adjacency unless an ISH is received.

    The unfortunate outcome is the = possibility of one implementation that does not
    send ISH PDUs over a = point-to-point link becoming connected to an alternative
    implementation that will not form = an adjacency unless it receives an ISH.

4. Deployed IS-IS and best practice

    Given that later versions of = ISO/IEC 10589 have been enterpreted as stating
    that no adjacency will be formed = until an ISH is received, the only way to
    initiate an adjacency with a = resultant implementation is to actually send
    an ISH.

    Therefore if interoperability is = wanted with such implementations, then an
    IS-IS router SHOULD send an ISH = PDUs over a point-to-point circuit whenever
    the circuit is first enabled, and = periodically whenever a circuit is Down,
    whether or not the router can = forward CLNP packets.

    Given that earlier versions of = ISO/IEC 10589 have been enterpreted as stating
    that ISH PDUs are not required if = CLNP forwarding is not supported, then the
    only way to initiate an adjacency = with a resultant implementation is to accept
    IIH PDUs in lieu of ISH = PDUs.

    Therefore if interoperability is = wanted with such implementations, then an
    IS-IS router SHOULD create an = adjacency with adjacencyState "Initialising" and
    send a point-to-point IIH PDU if = it receives an IIH PDU and no adjacency
    already exists.

5. Security Considerations

    This document raises no new = security issues for IS-IS.

6. References

    [1] R. Callon, "Use of OSI = IS-IS for Routing in TCP/IP and Dual
    Environments" RFC 1195, = December 1990

    [2] ISO, "Intermediate System = to Intermediate System Intra-
    Domain Routeing Exchange Protocol = for use in Conjunction with the
    Protocol for Providing the = Connectionless-mode Network Service (ISO
    8473)", ISO/IEC 10589:1992 =

------_=_NextPart_001_01C1B54A.034B2BF0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 06:44:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15381 for ; Thu, 14 Feb 2002 06:44:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EBa2L12170; Thu, 14 Feb 2002 03:36:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EBZuL12158 for ; Thu, 14 Feb 2002 03:35:56 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp91.cisco.com [10.50.0.90]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA25850; Thu, 14 Feb 2002 11:41:58 GMT Message-Id: <4.3.2.7.2.20020214110755.033fced8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Matthew Noble" From: mike shand Cc: "'Isis-Wg (E-mail)" In-Reply-To: <000001c1b544$948285b0$71d814ac@ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Isis-wg] Re: Format of Restart TLV Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 11:40:38 +0000 Matt, Hmmm. I see your point, but I'm not at all keen on making what is already an embarrassingly complex design even more complicated. A few points. In the general case, with a holding multiplier of 3, the worst diversity we would expect to see in the holding times would we about 30% [actually that is not true, since it is possible that one router fails, and then a couple of hello times later, the second fails. Then both come up more or less together. However, I'm not sure we should go overboard trying to deal with what are essentially two partially overlapping, but unrelated failures.] If there are multiple failures, and one router fails to come up in time to avoid a routing churn, then there is not much point in the other(s) persisting in trying to be stealthy, since chaos reigns anyway. I'm almost tempted to say that if there ARE two coincident failures then we should just do a hard restart anyway. There is a danger in trying to make this thing deal with ever more complex corner cases that we end up with something which is too complicated for its own good. That said, if people think the addition of a "I am responding to a restart by X" field would be beneficial, it does cost us much packet real estate. But I think it WILL cost us a lot in specsmanship to make sure it all works how we expect it to :-) Mike At 10:43 14/02/2002 +0000, Matthew Noble wrote: >Mike > > From your ISIS Restart draft, when a "helper" node responds to a Restart TLV >from a "restarter" node, it returns the RA bit set and the remaining time of >the adjacency holding time. This as it is is fine for p2p, but on a LAN >where there could be mutiple "restarter" nodes on the LAN, the info in the >broadcast IIH is specific to one "restarter" but will be received and >prcossed equally by all "restarter" nodes on that LAN. > >Should the remaining holding time in the restart TLV be qualified by the >sysid of the "restarter" to which it refers ? > >Omission of this qualification means that all the "restarter" nodes on the >LAN will use the minimum value of the remaining holding times sent out by >the "helper" nodes. This is not a disaster but reduces further the chances >that the "restarter" nodes will complete the restart process, and so >increase the possibility of churn in the routing tables. > >What do you think ? > >Thanks >Matt _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 08:01:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17046 for ; Thu, 14 Feb 2002 08:01:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1ECr1L12523; Thu, 14 Feb 2002 04:53:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bart.cwnt.com ([192.116.246.129]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1ECqhL12511 for ; Thu, 14 Feb 2002 04:52:44 -0800 (PST) (envelope-from amir@cwnt.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt Message-ID: Thread-Topic: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt Thread-Index: AcG1CeanlqblCzZtQ4yAaBrfd1cTAQAKJIUA From: "Amir Hermelin" To: "Alex Zinin" Cc: "ISIS-wg (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g1ECqiL12512 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 14:58:47 +0200 Content-Transfer-Encoding: 8bit Alex, originally, the request came from an ISP that is experimenting with distributing granular reachability info between L1 areas through an L2 backbone (RFC 2966). Assuming there is motivation for this RFC (maybe there isn't), then there is motivation to save space on reachability info. That is IMO more than enough motivation to implement mode 1 if you don't want to upgrade your entire network (as opposed to just the overloaded distribution points). This has been said before, and I'm finding it difficult understanding the objection to keeping mode 1. Still, I confess my choice of words "it's already written" wasn't very good :-) -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Alex Zinin [mailto:azinin@nexsi.com] > Sent: Thursday, February 14, 2002 5:44 AM > To: Amir Hermelin > Cc: ISIS-wg (E-mail) > Subject: Re: [Isis-wg] draft-hermelin-ext-lsp-frags-03.txt > > > > Amir, > > > Alex, > > thanks for your comments. > > As I recall from the last meeting, the "agreement" that > only mode 2 is needed > > was only stated by three or four people, and objected by > one or two (myself > > included) - hardly a consensus. > > You're probably right. > > > Some folks also approached me after the meeting and stated > that mode 1 is useful. > > The important part is this: the draft permits > implementation of only mode 2, so > > mode 1 is optional (as is the whole draft). > > I'm trying to understand the scenarios where mode 1 would really be > useful... I tend to think (though I might be wrong, and if so, please > correct me) that reachability information is probably not the major > contributing factor (since ISP folks use IGPs to "glue > loopbacks together" > and use BGP to distribute the actual routes) and hence off-loading it > to extended LSPs would not free much space in the standard LSPs. > > If this is the TE scenario, then most probably most if not all routers > in the network would experience the problem and a) all of > them would need > to be SW-upgraded with either mode, and b) we can't put much > more topological > info in the LSPs since we still have the same limitation for it. > > Could you (or anyone who cares) please shed some light on why you > think mode 1 is useful. Not trying to say it is necessarily not > useful, just trying to understand the motivation... > > > You don't need extra code, knobs, bugs, etc if your > customers don't want > > this. And since the text is already written, I don't see a > good argument > > for removing it (the text). Of course, whether or not both modes are > > implemented doesn't affect people who'll want to transition > to mode 2 eventually. > > Does that sound good to you? Any thoughts from the group on this? > > It is surely fine with me if mode 1 happens to add real value. > If not, I guess the argument "it's already written" does not > strike me as very persuasive technically ;) > > Regards, > > Alex. > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 08:37:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17658 for ; Thu, 14 Feb 2002 08:37:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EDT1L12724; Thu, 14 Feb 2002 05:29:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EDShL12712 for ; Thu, 14 Feb 2002 05:28:43 -0800 (PST) (envelope-from matthew.noble@riverstonenet.com) Received: from ssntw1 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id FAA03624; Thu, 14 Feb 2002 05:34:36 -0800 (PST) From: "Matthew Noble" To: "'mike shand'" Cc: "'Isis-Wg (E-mail)" Message-ID: <000101c1b55c$baad1ad0$71d814ac@ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <4.3.2.7.2.20020214110755.033fced8@jaws.cisco.com> Subject: [Isis-wg] RE: Format of Restart TLV Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 13:36:50 -0000 Content-Transfer-Encoding: 7bit Mike I agree with you that in many cases the addition of this extra sysid may be overkill but I think there may be situations where every chance of reducing the likelihood of churn should be taken. To that end, is it worth making the sysid optional? We could state that all zero's means "not defined - please ignore". Another option would be to make the TLV variable length, so that if the bytes are not there, they are not defined. This would save the space in _every_ IIH being transmitted. If this is acceptable, then we could make it so that if RR bit is set, then we dont include the (empty) space for the remaining holding time as well. Either way would allow the inclusion and/or processing of the sysid not to be implemented where vendors choose not to. Thanks Matt > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Thursday, February 14, 2002 11:41 AM > To: Matthew Noble > Cc: 'Isis-Wg (E-mail) > Subject: Re: Format of Restart TLV > > > Matt, > > Hmmm. I see your point, but I'm not at all keen on making > what is already > an embarrassingly complex design even more complicated. > > A few points. > > In the general case, with a holding multiplier of 3, the > worst diversity we > would expect to see in the holding times would we about 30% > [actually that > is not true, since it is possible that one router fails, and > then a couple > of hello times later, the second fails. Then both come up > more or less > together. However, I'm not sure we should go overboard trying > to deal with > what are essentially two partially overlapping, but unrelated > failures.] > > If there are multiple failures, and one router fails to come > up in time to > avoid a routing churn, then there is not much point in the other(s) > persisting in trying to be stealthy, since chaos reigns anyway. > > I'm almost tempted to say that if there ARE two coincident > failures then we > should just do a hard restart anyway. > > There is a danger in trying to make this thing deal with ever > more complex > corner cases that we end up with something which is too > complicated for its > own good. > > That said, if people think the addition of a "I am responding > to a restart > by X" field would be beneficial, it does cost us much packet > real estate. > But I think it WILL cost us a lot in specsmanship to make > sure it all works > how we expect it to :-) > > Mike > > > At 10:43 14/02/2002 +0000, Matthew Noble wrote: > >Mike > > > > From your ISIS Restart draft, when a "helper" node responds > to a Restart TLV > >from a "restarter" node, it returns the RA bit set and the > remaining time of > >the adjacency holding time. This as it is is fine for p2p, > but on a LAN > >where there could be mutiple "restarter" nodes on the LAN, > the info in the > >broadcast IIH is specific to one "restarter" but will be received and > >prcossed equally by all "restarter" nodes on that LAN. > > > >Should the remaining holding time in the restart TLV be > qualified by the > >sysid of the "restarter" to which it refers ? > > > >Omission of this qualification means that all the > "restarter" nodes on the > >LAN will use the minimum value of the remaining holding > times sent out by > >the "helper" nodes. This is not a disaster but reduces > further the chances > >that the "restarter" nodes will complete the restart process, and so > >increase the possibility of churn in the routing tables. > > > >What do you think ? > > > >Thanks > >Matt > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 08:50:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17992 for ; Thu, 14 Feb 2002 08:50:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EDh1L12831; Thu, 14 Feb 2002 05:43:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EDgLL12819 for ; Thu, 14 Feb 2002 05:42:21 -0800 (PST) (envelope-from matthew.noble@riverstonenet.com) Received: from ssntw1 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id FAA04459; Thu, 14 Feb 2002 05:48:15 -0800 (PST) From: "Matthew Noble" To: "Mike Shand (E-mail)" Cc: "'Isis-Wg (E-mail)" Message-ID: <000201c1b55e$a31dff90$71d814ac@ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Isis-wg] ISIS Restart - receipt of complete set of CSNP's Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 13:50:33 -0000 Content-Transfer-Encoding: 7bit Mike Another question. The main reason for stopping the timer T1 is when "a complete set of CSNP(s) and an acknowledgment" are received over the circuit. How can it be determined when the "complete set" of CSNP's has been received? The ISO spec infers that individual CSNP's are pretty much self-contained and that the order of receipt is not important (and therefore cannot be assumed) as long as the set taken together cover the whole contents of the sender's database. Thanks Matt _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 09:08:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18448 for ; Thu, 14 Feb 2002 09:08:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EE01L12938; Thu, 14 Feb 2002 06:00:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EDxdL12920 for ; Thu, 14 Feb 2002 05:59:39 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp91.cisco.com [10.50.0.90]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA01949; Thu, 14 Feb 2002 14:05:42 GMT Message-Id: <4.3.2.7.2.20020214140319.034524c0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Matthew Noble" From: mike shand Cc: "'Isis-Wg (E-mail)" In-Reply-To: <000201c1b55e$a31dff90$71d814ac@ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Isis-wg] Re: ISIS Restart - receipt of complete set of CSNP's Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 14:05:17 +0000 At 13:50 14/02/2002 +0000, Matthew Noble wrote: >Mike > >Another question. The main reason for stopping the timer T1 is when "a >complete set of CSNP(s) and an acknowledgment" are received over the >circuit. How can it be determined when the "complete set" of CSNP's has been >received? The ISO spec infers that individual CSNP's are pretty much >self-contained and that the order of receipt is not important (and therefore >cannot be assumed) as long as the set taken together cover the whole >contents of the sender's database. Exactly so. When you have a set which covers the whole contents of the database. i.e. you want to see a contiguous set (in any order which starts at 00...0000 and ends at FFF....FFF (can't be bothered to figure out how many digits :-) Mike >Thanks >Matt _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 10:34:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24411 for ; Thu, 14 Feb 2002 10:34:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EFQ6L13298; Thu, 14 Feb 2002 07:26:06 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EFPDL13286 for ; Thu, 14 Feb 2002 07:25:14 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 2456 invoked from network); 14 Feb 2002 15:31:16 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Feb 2002 15:31:16 -0000 From: "Ken Larmer" To: "Dave Katz" , Cc: Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200202131908.g1DJ88326823@cirrus.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 10:36:48 -0500 Content-Transfer-Encoding: 7bit > The only other use for ISH seems to be if a router wants to > act as an OSI End-System for some reason. I haven't quite > figured out why/when/if an OSI router needs to also have > End-System functionality, unless it is something to do with > OSI redirects. It would seem to me that if a router needs to > have ES functionality is could attach it to itself rather > than to its neighbour. What am I missing here? Why can't > you have an OSI router that is only an IS, and, if so why > does it need to worry about ISHs? > > You need ES functionality for network management (CMIP and TP4) if > you were going to be a full-blown OSI router, the Tucker Torpedo of > the networking world. Otherwise, the ISH serves no purpose at all. I have hesitated to mention this in a public forum because this practice may still be in use in some networks? But I believe if we take efforts on this list, which do not take the following possible scenario into account, we may unknowingly break current network implementations when they are upgraded with code which may not fully abide by ISO-10589. Though, I must state this is fairly unlikely given the evaluation of networks and network security over the past years. Let me explain below: One could perceive of a scenario where a network is configured with its primary management path being an in-band (Telnet, SNMP, CMIP...). Say that path gets broken. Well, there could be a highly secure out-of-band backup path for recovery which may also serve as a primary path for software upgrades. The security advantages of being able to connect an ES only implementation directly to an IS are considerable in my opinion. Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 14:37:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07651 for ; Thu, 14 Feb 2002 14:37:31 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EJT1L14338; Thu, 14 Feb 2002 11:29:06 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EJSpL14326 for ; Thu, 14 Feb 2002 11:28:51 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EJYmN17730; Thu, 14 Feb 2002 14:34:49 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EJYfP07641; Thu, 14 Feb 2002 20:34:45 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EJYGM28093; Thu, 14 Feb 2002 19:34:16 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS8A87S>; Thu, 14 Feb 2002 19:34:39 -0000 Message-ID: <4103264BC8D3D51180B7002048400C4507150B@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Ken Larmer'" , Dave Katz Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B58E.A608E9B0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 19:34:41 -0000 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_01C1B58E.A608E9B0 Content-Type: text/plain; charset="iso-8859-1" I think that if you can forward CLNP packets, then it is pretty clear that you MUST conform with ISO 10589, and therefore MUST send ISHs, and MUST be able to connect to ESs. Hence the whole issue of whether you send ISH or not, and what you do if you don't receive one, is simply irrelevant to routers that support CLNP forwarding. It really is only a problem for IP-only routers, and maybe a dual router that might get connected to an IP-only router and thus not receive an ISH. A dual router connected to a dual router will always receive an ISH as the other end will have to send one in order to connect to ESs anyway. Also in the SONET/SDH world it is quite possible that someone might make their SONET/SDH ADM (Add Drop Multiplexer) an ES. For example if you have an IP managed ADM then you might think that ES only functionality is all that is needed to terminate RFC 3147 encapsulated IP packets for example. In this case your ADM (an ES) would be connected to some other ADM (an IS) across an embedded DCC link, which is a point-to-point link, and the point-to-point ISH is clearly needed. Philip. > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: 14 February 2002 15:37 > To: Dave Katz; Christian, Philip [HAL02:GI50:EXCH] > Cc: isis-wg@spider.juniper.net > Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH > > > > > The only other use for ISH seems to be if a router wants to > > act as an OSI End-System for some reason. I haven't quite > > figured out why/when/if an OSI router needs to also have > > End-System functionality, unless it is something to do with > > OSI redirects. It would seem to me that if a router needs to > > have ES functionality is could attach it to itself rather > > than to its neighbour. What am I missing here? Why can't > > you have an OSI router that is only an IS, and, if so why > > does it need to worry about ISHs? > > > > You need ES functionality for network management (CMIP and TP4) if > > you were going to be a full-blown OSI router, the Tucker Torpedo of > > the networking world. Otherwise, the ISH serves no purpose at all. > > I have hesitated to mention this in a public forum > because this practice > may still be in use in some networks? But I believe if we > take efforts on > this list, which do not take the following possible scenario > into account, > we may unknowingly break current network implementations when they are > upgraded with code which may not fully abide by ISO-10589. > Though, I must > state this is fairly unlikely given the evaluation of > networks and network > security over the past years. Let me explain below: > > One could perceive of a scenario where a network is > configured with its > primary management path being an in-band (Telnet, SNMP, > CMIP...). Say that > path gets broken. Well, there could be a highly secure > out-of-band backup > path for recovery which may also serve as a primary path for software > upgrades. The security advantages of being able to connect an ES only > implementation directly to an IS are considerable in my opinion. > > Cheers, > Ken Larmer > CommSense Networks > > ------_=_NextPart_001_01C1B58E.A608E9B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Question on the usage of ISH and P2PIIH

I think that if you can forward CLNP packets, then it = is pretty clear that you MUST conform with ISO 10589, and therefore = MUST send ISHs, and MUST be able to connect to ESs.

Hence the whole issue of whether you send ISH or not, = and what you do if you don't receive one, is simply irrelevant to = routers that support CLNP forwarding.

It really is only a problem for IP-only routers, and = maybe a dual router that might get connected to an IP-only router and = thus not receive an ISH.  A dual router connected to a dual router = will always receive an ISH as the other end will have to send one in = order to connect to ESs anyway.

Also in the SONET/SDH world it is quite possible that = someone might make their SONET/SDH ADM (Add Drop Multiplexer) an = ES.

For example if you have an IP managed ADM then you = might think that ES only functionality is all that is needed to = terminate RFC 3147 encapsulated IP packets for example.

In this case your ADM (an ES) would be connected to = some other ADM (an IS) across an embedded DCC link, which is a = point-to-point link, and the point-to-point ISH is clearly = needed.

Philip.

> -----Original Message-----
> From: Ken Larmer [mailto:Larmer@CommSense.Net]
> Sent: 14 February 2002 15:37
> To: Dave Katz; Christian, Philip = [HAL02:GI50:EXCH]
> Cc: isis-wg@spider.juniper.net
> Subject: RE: [Isis-wg] Question on the usage of = ISH and P2PIIH
>
>
>
> >    The only other use for = ISH seems to be if a router wants to
> >    act as an OSI End-System = for some reason.  I haven't quite
> >    figured out why/when/if = an OSI router needs to also have
> >    End-System = functionality, unless it is something to do with
> >    OSI redirects.  It = would seem to me that if a router needs to
> >    have ES functionality is = could attach it to itself rather
> >    than to its = neighbour.  What am I missing here?  Why can't
> >    you have an OSI router = that is only an IS, and, if so why
> >    does it need to worry = about ISHs?
> >
> > You need ES functionality for network = management (CMIP and TP4) if
> > you were going to be a full-blown OSI = router, the Tucker Torpedo of
> > the networking world.  Otherwise, the = ISH serves no purpose at all.
>
>       I have hesitated = to mention this in a public forum
> because this practice
> may still be in use in some networks? But I = believe if we
> take efforts on
> this list, which do not take the following = possible scenario
> into account,
> we may unknowingly break current network = implementations when they are
> upgraded with code which may not fully abide by = ISO-10589.
> Though, I must
> state this is fairly unlikely given the = evaluation of
> networks and network
> security over the past years. Let me explain = below:
>
>       One could = perceive of a scenario where a network is
> configured with its
> primary management path being an in-band = (Telnet, SNMP,
> CMIP...). Say that
> path gets broken. Well, there could be a highly = secure
> out-of-band backup
> path for recovery which may also serve as a = primary path for software
> upgrades. The security advantages of being able = to connect an ES only
> implementation directly to an IS are = considerable in my opinion.
>
> Cheers,
> Ken Larmer
> CommSense Networks
>
>

------_=_NextPart_001_01C1B58E.A608E9B0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 15:49:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09315 for ; Thu, 14 Feb 2002 15:49:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EKf1L14675; Thu, 14 Feb 2002 12:41:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EKe9L14663 for ; Thu, 14 Feb 2002 12:40:09 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 26796 invoked from network); 14 Feb 2002 20:46:17 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Feb 2002 20:46:17 -0000 From: "Ken Larmer" To: "Philip Christian" , "Dave Katz" Cc: Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C1B56F.836890F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <4103264BC8D3D51180B7002048400C4507150B@zhard0jd.europe.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 15:51:49 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C1B56F.836890F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [Isis-wg] Question on the usage of ISH and P2PIIH I think that if you can forward CLNP packets, then it is pretty clear that you MUST conform with ISO 10589, and therefore MUST send ISHs, and MUST be able to connect to ESs. Hence the whole issue of whether you send ISH or not, and what you do if you don't receive one, is simply irrelevant to routers that support CLNP forwarding. It really is only a problem for IP-only routers, and maybe a dual router that might get connected to an IP-only router and thus not receive an ISH. A dual router connected to a dual router will always receive an ISH as the other end will have to send one in order to connect to ESs anyway. Also in the SONET/SDH world it is quite possible that someone might make their SONET/SDH ADM (Add Drop Multiplexer) an ES. For example if you have an IP managed ADM then you might think that ES only functionality is all that is needed to terminate RFC 3147 encapsulated IP packets for example. In this case your ADM (an ES) would be connected to some other ADM (an IS) across an embedded DCC link, which is a point-to-point link, and the point-to-point ISH is clearly needed. Philip. Yes, that was my original point. It is possible to have an OSI ES connected to a Dual-IS, which uses CLNP and/or IP as its data transport mechanism. In addition, it is also possible to have an OSI ES connected to an IP-Only IS, which uses IP as its data transport mechanism and NOT CLNP. Consequently, as Philip pointed out, this is not simply a concern for a Dual-IS or an OSI-Only IS, it will also impact an IP-Only IS's capability to communicate properly with an OSI ES which uses IP as its data transport mechanism. This leads to a larger point. While I believe, as others do on this list, that ISO-10589 in combination with RFC-1195 are very well thought out specifications for a Link State IGP, they both (IMHO) fall short in their explanation of why they do certain things the way they do. As a consequence, it may appear harmless on the surface to remove and/or ignore certain sections from either specification, but in practicality it may not be the smartest thing to do unless you fully understand the ramifications of your actions. Cheers, Ken Larmer CommSense Networks ------=_NextPart_000_0045_01C1B56F.836890F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Question on the usage of ISH and = P2PIIH
 
I think that=20 if you can forward CLNP packets, then it is pretty clear that you MUST = conform=20 with ISO 10589, and therefore MUST send ISHs, and MUST be able to = connect to=20 ESs.

Hence the whole issue of whether you send ISH or = not, and what=20 you do if you don't receive one, is simply irrelevant to routers that = support=20 CLNP forwarding.

It really is only a problem for IP-only routers, and = maybe a=20 dual router that might get connected to an IP-only router and thus not = receive=20 an ISH.  A dual router connected to a dual router will always = receive an=20 ISH as the other end will have to send one in order to connect to ESs=20 anyway.

Also in the SONET/SDH world it is quite possible = that someone=20 might make their SONET/SDH ADM (Add Drop Multiplexer) an = ES.

For example if you have an IP managed ADM then you = might think=20 that ES only functionality is all that is needed to terminate RFC 3147 = encapsulated IP packets for example.

In this case your ADM (an ES) would be connected to = some other=20 ADM (an IS) across an embedded DCC link, which is a point-to-point = link, and=20 the point-to-point ISH is clearly needed. 

 Philip.  

    Yes, that=20 was my original point. It is possible to have an OSI ES connected to a = Dual-IS,=20 which uses CLNP and/or IP as its data transport = mechanism.  In=20 addition, it is also possible to have an OSI ES connected to an IP-Only = IS,=20 which uses IP as its data transport mechanism and NOT = CLNP.=20 Consequently, as Philip pointed out, this is not simply a concern for a = Dual-IS=20 or an OSI-Only IS, it will also impact an IP-Only IS's capability = to=20 communicate properly with an OSI ES which uses IP as its data transport=20 mechanism.
 
    This leads to a larger point. While I believe, as others do on = this list,=20 that ISO-10589 in combination with RFC-1195 are very well thought=20 out specifications for a Link State IGP, they both (IMHO) fall = short in=20 their explanation of why they do certain things the way they do. As a=20 consequence, it may appear harmless on the surface to remove and/or = ignore=20 certain sections from either specification, but in practicality it may = not be=20 the smartest thing to do unless you fully understand the ramifications = of your=20 actions. 
 
Cheers,
Ken=20 Larmer
CommSense=20 Networks 
------=_NextPart_000_0045_01C1B56F.836890F0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 16:02:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09597 for ; Thu, 14 Feb 2002 16:02:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EKs1L14775; Thu, 14 Feb 2002 12:54:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EKrqL14763 for ; Thu, 14 Feb 2002 12:53:52 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1EKxu673371; Thu, 14 Feb 2002 12:59:56 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g1EKxuV31320; Thu, 14 Feb 2002 12:59:56 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200202142059.g1EKxuV31320@cirrus.juniper.net> From: Dave Katz To: Larmer@commsense.net CC: christi@nortelnetworks.com, isis-wg@spider.juniper.net In-reply-to: Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 12:59:56 -0800 (PST) Yes, that was my original point. It is possible to have an OSI ES connected to a Dual-IS, which uses CLNP and/or IP as its data transport mechanism. In addition, it is also possible to have an OSI ES connected to an IP-Only IS, which uses IP as its data transport mechanism and NOT CLNP. Consequently, as Philip pointed out, this is not simply a concern for a Dual-IS or an OSI-Only IS, it will also impact an IP-Only IS's capability to communicate properly with an OSI ES which uses IP as its data transport mechanism. This makes no sense at all. If the IS is IP-only, the fact that the ES is OSI-capable makes no difference to anyone, and the ES will be acting as an IP host and using IP mechanisms, and the ISH would serve no purpose. I'm kind of at a loss as to why this issue is so hard to codify. It seems simple to me: IP-only ISs may not send ISHs, so all ISs should be prepared to create an ISIS adjacency based only on the receipt of an IIH, which most of them probably already would do anyhow. The use of ISHs is of no functional use in non-OSI routers, and only adds code and complexity. This leads to a larger point. While I believe, as others do on this list, that ISO-10589 in combination with RFC-1195 are very well thought out specifications for a Link State IGP, they both (IMHO) fall short in their explanation of why they do certain things the way they do. As a consequence, it may appear harmless on the surface to remove and/or ignore certain sections from either specification, but in practicality it may not be the smartest thing to do unless you fully understand the ramifications of your actions. This is universally true of routing protocol specs. I think OSPF is even worse in this respect, as it is inherently more complex, and breaks easily if you don't follow the rules exactly. (But as a knowledgable implementor, it gives me a competitive edge.) FWIW, I was not a signficant contributor to either spec, so it's not my fault. ;-) --Dave _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 16:15:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09960 for ; Thu, 14 Feb 2002 16:15:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EL71L14865; Thu, 14 Feb 2002 13:07:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EL6tL14853 for ; Thu, 14 Feb 2002 13:06:55 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 7360 invoked from network); 14 Feb 2002 21:13:04 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 Feb 2002 21:13:04 -0000 From: "Ken Larmer" To: "Dave Katz" Cc: , Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200202142059.g1EKxuV31320@cirrus.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 16:18:36 -0500 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Thursday, February 14, 2002 4:00 PM > To: Larmer@commsense.net > Cc: christi@nortelnetworks.com; isis-wg@spider.juniper.net > Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH > > > Yes, that was my original point. It is possible to have an OSI ES > connected to a Dual-IS, which uses CLNP and/or IP as its data transport > mechanism. In addition, it is also possible to have an OSI ES > connected to > an IP-Only IS, which uses IP as its data transport mechanism > and NOT CLNP. > Consequently, as Philip pointed out, this is not simply a concern for a > Dual-IS or an OSI-Only IS, it will also impact an IP-Only IS's > capability to > communicate properly with an OSI ES which uses IP as its data transport > mechanism. > > This makes no sense at all. If the IS is IP-only, the fact that the > ES is OSI-capable makes no difference to anyone, and the ES will be > acting as an IP host and using IP mechanisms, and the ISH would serve > no purpose. Dave, how does an IP-only IS form an adjacency with an OSI-ES over a PtP link if it does not use the ESIS protocol (other than the use of static routes which are always present)? Remember, these are very specific cases we are talking about here with use of an OSI-ES in this scenario. I am not saying that there are not other methods of accomplishing this same capability through use of different mechanisms. Ken _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 16:19:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10050 for ; Thu, 14 Feb 2002 16:19:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1ELC1L14909; Thu, 14 Feb 2002 13:12:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1ELB2L14897 for ; Thu, 14 Feb 2002 13:11:02 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g1ELH7674582; Thu, 14 Feb 2002 13:17:07 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g1ELH7h31422; Thu, 14 Feb 2002 13:17:07 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200202142117.g1ELH7h31422@cirrus.juniper.net> From: Dave Katz To: Larmer@commsense.net CC: christi@nortelnetworks.com, isis-wg@spider.juniper.net In-reply-to: Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH References: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 13:17:07 -0800 (PST) Dave, how does an IP-only IS form an adjacency with an OSI-ES over a PtP link if it does not use the ESIS protocol (other than the use of static routes which are always present)? Remember, these are very specific cases we are talking about here with use of an OSI-ES in this scenario. I am not saying that there are not other methods of accomplishing this same capability through use of different mechanisms. It doesn't. Why would it? It's an IP host with default route pointing at the point-to-point link, or if you're really lucky it is smart enough to listen to the router discovery protocol. The fact that it speaks OSI takes up memory in the system but is otherwise interesting. The router by definition won't forward its CLNP packets anyhow. There are well-known IP mechanisms for accomplishing this stuff. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 17:11:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11335 for ; Thu, 14 Feb 2002 17:11:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EM31L15168; Thu, 14 Feb 2002 14:03:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EM28L15156 for ; Thu, 14 Feb 2002 14:02:08 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EM85N28278; Thu, 14 Feb 2002 17:08:06 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EM82P14197; Thu, 14 Feb 2002 23:08:02 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EM7cM05585; Thu, 14 Feb 2002 22:07:38 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS8A04S>; Thu, 14 Feb 2002 22:08:00 -0000 Message-ID: <4103264BC8D3D51180B7002048400C4507150C@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Ken Larmer'" , Dave Katz Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B5A4.1289A880" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 22:08:03 -0000 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_01C1B5A4.1289A880 Content-Type: text/plain; charset="iso-8859-1" Sorry, but that was not what I said. I said that in the SONET/SDH world people might still want to connect OSI End Systems over a point-to-point link to an OSI router (and ADM). That's all it is. My point was that OSI End Systems are not useless, and you might actually want to use one in a SONET/SDH DCC channel. This is useful because you can use an ES to terminate CLNP packets that happen to contain IP inside them using RFC 3147, which are then forwarded to a seperate IP stack in the ADM. This is not connecting an OSI End System to an IP-only router. IP-only routers cannot forward CLNP packets, and so are useless to an OSI End System. ES-IS might come up, but any CLNP packets just won't get through. Philip as Philip pointed out, this is not simply a concern for a Dual-IS or an OSI-Only IS, it will also impact an IP-Only IS's capability to communicate properly with an OSI ES which uses IP as its data transport mechanism. ------_=_NextPart_001_01C1B5A4.1289A880 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Question on the usage of ISH and P2PIIH
Sorry, but that was not what I said.
 
I said that in the SONET/SDH world people might still want to connect OSI End Systems over a point-to-point link to an OSI router (and ADM).
That's all it is.
My point was that OSI End Systems are not useless, and you might actually want to use one in a SONET/SDH DCC channel.
 
This is useful because you can use an ES to terminate CLNP packets that happen to contain IP inside them using RFC 3147, which are then forwarded to a seperate IP stack in the ADM.
 
This is not connecting an OSI End System to an IP-only router.
IP-only routers cannot forward CLNP packets, and so are useless to an OSI End System. ES-IS might come up, but any CLNP packets just won't get through.
 
Philip
 
as Philip pointed out, this is not simply a concern for a Dual-IS or an OSI-Only IS, it will also impact an IP-Only IS's capability to communicate properly with an OSI ES which uses IP as its data transport mechanism.
 
------_=_NextPart_001_01C1B5A4.1289A880-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 22:25:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16629 for ; Thu, 14 Feb 2002 22:25:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1F3H1L16409; Thu, 14 Feb 2002 19:17:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.227.69]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1F3GrL16397 for ; Thu, 14 Feb 2002 19:16:53 -0800 (PST) (envelope-from svemulap@cisco.com) Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.102.160]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA05092 for ; Thu, 14 Feb 2002 19:23:03 -0800 (PST) From: Shankar Vemulapalli To: isis-wg@spider.juniper.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Isis-wg] Reg. draft-ietf-isis-wg-tlv-codepoints-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 19:22:37 -0800 (PST) Hi, Since the draft-ietf-isis-wg-tlv-codepoints-01.tx talks about the ISIS TLVs - it would be good to include the sub-TLVs also - so that we can have all the ISIS-related TLVs at one place. ISIS-Sub-TLVs include: [for reference- try to cover most of them below] Name TLVs Draft _______________________________________________________________________________ Administrative Tag 1 draft-ietf-isis-igp-p2p-over-lan-00.txt Admin. Group(color) 3 draft-ietf-isis-traffic-04.txt Outgoing Int. Indetifier 4 draft-ietf-isis-gmpls-extensions-08.txt Incoming Int. Identifier 5 draft-ietf-isis-gmpls-extensions-08.txt IPv4 Inter. Address 6 draft-ietf-isis-traffic-04.txt Interface MTU 7 IPv4 Neigh. Address 8 draft-ietf-isis-traffic-04.txt Maximum Link Bandwidth 9 draft-ietf-isis-traffic-04.txt Max. Reserv. Link Bandwidth 10 draft-ietf-isis-traffic-04.txt Unreveserved Bandwidth 11 draft-ietf-isis-traffic-04.txt TE Default Metric 18 draft-ietf-isis-traffic-04.txt Link Protection Type 20 Int. Swith. Capability Desc. 21 draft-ietf-isis-gmpls-extensions-08.txt MT Reachable IPv4 Prefixes 117 draft-ietf-isis-wg-multi-topology-02.txt Reserved for Cisco Specific 250-254 draft-ietf-isis-traffic-04.txt Reserved for Future Exapans 255 draft-ietf-isis-traffic-04.txt --------------------------------------------------------------------------------- Just a thought - Thanks, /Shankar _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 14 22:36:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17717 for ; Thu, 14 Feb 2002 22:36:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1F3T2L16487; Thu, 14 Feb 2002 19:29:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1F3SlL16475 for ; Thu, 14 Feb 2002 19:28:47 -0800 (PST) (envelope-from prz@redback.com) Received: from redback.com ([63.200.49.216]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GRK00GL01Y8YV@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Thu, 14 Feb 2002 19:34:57 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] Reg. draft-ietf-isis-wg-tlv-codepoints-01.txt To: Shankar Vemulapalli Cc: isis-wg@spider.juniper.net Message-id: <3C6C6305.28C01A81@redback.com> 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: Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 17:23:18 -0800 Content-Transfer-Encoding: 7BIT Shankar Vemulapalli wrote: > Hi, > > Since the draft-ietf-isis-wg-tlv-codepoints-01.tx talks about the ISIS TLVs - > it would be good to include the sub-TLVs also - so that we can have all the > ISIS-related TLVs at one place. > > ISIS-Sub-TLVs include: [for reference- try to cover most of them below] > > Name TLVs Draft > _______________________________________________________________________________ > Administrative Tag 1 draft-ietf-isis-igp-p2p-over-lan-00.txt > Admin. Group(color) 3 draft-ietf-isis-traffic-04.txt > > Outgoing Int. Indetifier 4 draft-ietf-isis-gmpls-extensions-08.txt > Incoming Int. Identifier 5 draft-ietf-isis-gmpls-extensions-08.txt > > IPv4 Inter. Address 6 draft-ietf-isis-traffic-04.txt > Interface MTU 7 > > IPv4 Neigh. Address 8 draft-ietf-isis-traffic-04.txt > Maximum Link Bandwidth 9 draft-ietf-isis-traffic-04.txt > > Max. Reserv. Link Bandwidth 10 draft-ietf-isis-traffic-04.txt > Unreveserved Bandwidth 11 draft-ietf-isis-traffic-04.txt > > TE Default Metric 18 draft-ietf-isis-traffic-04.txt > Link Protection Type 20 > > Int. Swith. Capability Desc. 21 draft-ietf-isis-gmpls-extensions-08.txt > MT Reachable IPv4 Prefixes 117 draft-ietf-isis-wg-multi-topology-02.txt > > Reserved for Cisco Specific 250-254 draft-ietf-isis-traffic-04.txt > Reserved for Future Exapans 255 draft-ietf-isis-traffic-04.txt > --------------------------------------------------------------------------------- said to a couple of people privately, will repeat here on the list: this draft/RFC will _NOT_ track any sub-tlvs, just too much and varying too fast Divide & Conquer -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 00:16:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19277 for ; Fri, 15 Feb 2002 00:16:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1F581L16904; Thu, 14 Feb 2002 21:08:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.nexsi.com (system134.nexsi.com [66.35.197.134]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1F57aL16892 for ; Thu, 14 Feb 2002 21:07:36 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from khonsu.sw.nexsi.com (khonsu.sw.nexsi.com [192.168.104.115] (may be forged)) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id VAA29182; Thu, 14 Feb 2002 21:11:55 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <114204624354.20020214211315@nexsi.com> To: "Matthew Noble" CC: "'mike shand'" , "'Isis-Wg (E-mail)" Subject: Re: [Isis-wg] RE: Format of Restart TLV In-Reply-To: <000101c1b55c$baad1ad0$71d814ac@ctron.com> References: <000101c1b55c$baad1ad0$71d814ac@ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 21:13:15 -0800 Content-Transfer-Encoding: 7bit Matthew, I tend to agree with Mike here. The discussion of whether multiple restarting routers are ok or dangerous would be subjective and most probably fruitless, as both opinions are acceptable. So, let's use the KISS principle as the tie-breaker. The doc should, of course, spell out the situation you described. -- Alex Zinin Thursday, February 14, 2002, 5:36:50 AM, Matthew Noble wrote: > Mike > I agree with you that in many cases the addition of this extra sysid may be > overkill but I think there may be situations where every chance of reducing > the likelihood of churn should be taken. > To that end, is it worth making the sysid optional? We could state that all > zero's means "not defined - please ignore". > Another option would be to make the TLV variable length, so that if the > bytes are not there, they are not defined. This would save the space in > _every_ IIH being transmitted. If this is acceptable, then we could make it > so that if RR bit is set, then we dont include the (empty) space for the > remaining holding time as well. > Either way would allow the inclusion and/or processing of the sysid not to > be implemented where vendors choose not to. > Thanks > Matt _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 08:44:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05061 for ; Fri, 15 Feb 2002 08:44:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FDa1L19351; Fri, 15 Feb 2002 05:36:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FDZ8L19339 for ; Fri, 15 Feb 2002 05:35:08 -0800 (PST) (envelope-from matthew.noble@riverstonenet.com) Received: from ssntw1 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id FAA28678; Fri, 15 Feb 2002 05:41:07 -0800 (PST) From: "Matthew Noble" To: "'Alex Zinin'" , "'mike shand'" Cc: "'Isis-Wg (E-mail)" Subject: RE: [Isis-wg] RE: Format of Restart TLV Message-ID: <000001c1b626$d102d200$70d814ac@ctron.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <114204624354.20020214211315@nexsi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 13:43:27 -0000 Content-Transfer-Encoding: 7bit Alex/Mike The more I think of the scenarios where this might occur the more I agree with the KISS principle. Let's stick to how it is right now and just highlight the situation in the draft. Thanks Matt > -----Original Message----- > From: Alex Zinin [mailto:azinin@nexsi.com] > Sent: Friday, February 15, 2002 5:13 AM > To: Matthew Noble > Cc: 'mike shand'; 'Isis-Wg (E-mail) > Subject: Re: [Isis-wg] RE: Format of Restart TLV > > > > Matthew, > > I tend to agree with Mike here. > > The discussion of whether multiple restarting routers are ok > or dangerous would be subjective and most probably fruitless, > as both opinions are acceptable. So, let's use the KISS > principle as the tie-breaker. The doc should, of course, > spell out the situation you described. > > -- > Alex Zinin > > Thursday, February 14, 2002, 5:36:50 AM, Matthew Noble wrote: > > > Mike > > > I agree with you that in many cases the addition of this > extra sysid may be > > overkill but I think there may be situations where every > chance of reducing > > the likelihood of churn should be taken. > > > To that end, is it worth making the sysid optional? We > could state that all > > zero's means "not defined - please ignore". > > > Another option would be to make the TLV variable length, so > that if the > > bytes are not there, they are not defined. This would save > the space in > > _every_ IIH being transmitted. If this is acceptable, then > we could make it > > so that if RR bit is set, then we dont include the (empty) > space for the > > remaining holding time as well. > > > Either way would allow the inclusion and/or processing of > the sysid not to > > be implemented where vendors choose not to. > > > Thanks > > Matt > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 09:01:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05408 for ; Fri, 15 Feb 2002 09:01:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FDr1L19447; Fri, 15 Feb 2002 05:53:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FDqVL19435 for ; Fri, 15 Feb 2002 05:52:32 -0800 (PST) (envelope-from mshand@cisco.com) Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp2.cisco.com [10.50.0.1]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA29375; Fri, 15 Feb 2002 13:58:39 GMT Message-Id: <4.3.2.7.2.20020215140058.02d9f1b0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Matthew Noble" From: mike shand Subject: RE: [Isis-wg] RE: Format of Restart TLV Cc: "'Alex Zinin'" , "'Isis-Wg (E-mail)" In-Reply-To: <000001c1b626$d102d200$70d814ac@ctron.com> References: <114204624354.20020214211315@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 14:01:11 +0000 At 13:43 15/02/2002 +0000, Matthew Noble wrote: >Alex/Mike > >The more I think of the scenarios where this might occur the more I agree >with the KISS principle. Let's stick to how it is right now and just >highlight the situation in the draft. Sounds good to me. Mike >Thanks >Matt > > > -----Original Message----- > > From: Alex Zinin [mailto:azinin@nexsi.com] > > Sent: Friday, February 15, 2002 5:13 AM > > To: Matthew Noble > > Cc: 'mike shand'; 'Isis-Wg (E-mail) > > Subject: Re: [Isis-wg] RE: Format of Restart TLV > > > > > > > > Matthew, > > > > I tend to agree with Mike here. > > > > The discussion of whether multiple restarting routers are ok > > or dangerous would be subjective and most probably fruitless, > > as both opinions are acceptable. So, let's use the KISS > > principle as the tie-breaker. The doc should, of course, > > spell out the situation you described. > > > > -- > > Alex Zinin > > > > Thursday, February 14, 2002, 5:36:50 AM, Matthew Noble wrote: > > > > > Mike > > > > > I agree with you that in many cases the addition of this > > extra sysid may be > > > overkill but I think there may be situations where every > > chance of reducing > > > the likelihood of churn should be taken. > > > > > To that end, is it worth making the sysid optional? We > > could state that all > > > zero's means "not defined - please ignore". > > > > > Another option would be to make the TLV variable length, so > > that if the > > > bytes are not there, they are not defined. This would save > > the space in > > > _every_ IIH being transmitted. If this is acceptable, then > > we could make it > > > so that if RR bit is set, then we dont include the (empty) > > space for the > > > remaining holding time as well. > > > > > Either way would allow the inclusion and/or processing of > > the sysid not to > > > be implemented where vendors choose not to. > > > > > Thanks > > > Matt > > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 09:04:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05507 for ; Fri, 15 Feb 2002 09:04:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FDv1L19490; Fri, 15 Feb 2002 05:57:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FDuIL19473 for ; Fri, 15 Feb 2002 05:56:18 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1FE2kU29758; Fri, 15 Feb 2002 09:02:46 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-432.cisco.com [10.82.241.176]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAT81111; Fri, 15 Feb 2002 09:02:27 -0500 (EST) Message-Id: <4.3.2.7.2.20020215084111.03c38008@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dave Katz From: Jeff Learman Subject: Re: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: Larmer@commsense.net, christi@nortelnetworks.com, isis-wg@spider.juniper.net In-Reply-To: <200202142117.g1ELH7h31422@cirrus.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 09:02:21 -0500 At 04:17 PM 2/14/2002, Dave Katz wrote: > Dave, how does an IP-only IS form an adjacency with an OSI-ES over a PtP > link if it does not use the ESIS protocol (other than the use of static > routes which are always present)? Remember, these are very specific cases we > are talking about here with use of an OSI-ES in this scenario. I am not > saying that there are not other methods of accomplishing this same > capability through use of different mechanisms. > >It doesn't. Why would it? It's an IP host with default route >pointing at the point-to-point link, or if you're really lucky it is >smart enough to listen to the router discovery protocol. The fact >that it speaks OSI takes up memory in the system but is otherwise >interesting. The router by definition won't forward its CLNP packets >anyhow. There are well-known IP mechanisms for accomplishing this >stuff. Having some experience in this area (not at Cisco), I agree with Dave. The pertinent ISH would have to come from the other endpoint of the CLNP/IP tunnel, not from the adjacent IP-only router. In fact, the ADM must be careful to realize that any ISH it might receive from an IP-only neighbor is NOT to be fed to the local ESIS RIB database for use with CLNP. If the ADM is running ISIS this isn't a problem, because ISIS will figure out what's going on. This has interesting consequences in the discussion (not pertinent to this list) about multiprotocol encapsulation on SONET DCC and deployment rules. I think it means that an IP-only router should NOT send an ISH, to avoid creating the impression that it supports CLNP if a multiprotocol ES happens to be at the other end. (If an OSI-only ES is at the other end, it's misconnected, and it won't work regardless of whether it sends an ISH.) Regards, Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 10:25:33 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08048 for ; Fri, 15 Feb 2002 10:25:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FFH1L19852; Fri, 15 Feb 2002 07:17:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FFGpL19840 for ; Fri, 15 Feb 2002 07:16:51 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 20433 invoked from network); 15 Feb 2002 15:23:02 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Feb 2002 15:23:02 -0000 From: "Ken Larmer" To: "Dave Katz" Cc: , Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200202142117.g1ELH7h31422@cirrus.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 10:28:35 -0500 Content-Transfer-Encoding: 7bit > Dave, how does an IP-only IS form an adjacency with an > OSI-ES over a PtP > link if it does not use the ESIS protocol (other than the use of static > routes which are always present)? Remember, these are very > specific cases we > are talking about here with use of an OSI-ES in this scenario. I am not > saying that there are not other methods of accomplishing this same > capability through use of different mechanisms. > > It doesn't. Why would it? It's an IP host with default route > pointing at the point-to-point link, or if you're really lucky it is > smart enough to listen to the router discovery protocol. The fact > that it speaks OSI takes up memory in the system but is otherwise > interesting. The router by definition won't forward its CLNP packets > anyhow. There are well-known IP mechanisms for accomplishing this > stuff. OK! Just one final point and then I'll stop my crusade. I realize that given today's technological advances in the IP arena, this makes no sense. But, given the time and need, this sort of configuration did make sense. A DECnet Phase V ES possesses the capabilities to transport its data via CLNP and/or IP. Given that scenario and the fact that one of the first Integrated IS-IS routers released was OSI based and not IP based, would it not make sense to possess the above capabilities for remote management purposes. Especially if you had a mix of OSI and IP based IS routers in your network domain. Dave, I am not trying to create a stink here! I am simply trying to point out some network configurations (tier 1, large enterprise and significantly complex and large banking networks) I am very familiar with that have used this mechanism for remote management in the past. I believe fixing something which (IMHO) is not broken can lead to limitations in the protocol which may impact a particular customer's ability to upgrade with out reconfiguring their entire network management infrastructure. Of course, there is the other side to this coin, how long do we provide backward compatibility for networks which MAY be out dated? OK, time to fade away... :^) Cheers, Ken Larmer CommSense Networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 10:53:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08876 for ; Fri, 15 Feb 2002 10:53:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FFj1L20024; Fri, 15 Feb 2002 07:45:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FFiSL20009 for ; Fri, 15 Feb 2002 07:44:28 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zctfs063.nortelnetworks.com (zctfs063.europe.nortel.com [47.164.128.120]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FFoVT07662; Fri, 15 Feb 2002 10:50:31 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FFoSW09735; Fri, 15 Feb 2002 16:50:28 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FFo3620035; Fri, 15 Feb 2002 15:50:03 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS8CGVK>; Fri, 15 Feb 2002 15:50:25 -0000 Message-ID: <4103264BC8D3D51180B7002048400C45071512@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Ken Larmer'" , Dave Katz Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B638.79F9EA90" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 15:50:22 -0000 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_01C1B638.79F9EA90 Content-Type: text/plain; charset="iso-8859-1" Ahh! I think that I know what Ken means. I think that the suggestion is that if you have dual routers (IP and CLNP), then, why not manage them using OSI based management tools, instead of IP ones. The advantage would be that it would be hard to hack them as CLNP doesn't get routed by the Internet, and know-one out there has the tools. Security by obscurity! I too have been thinking that SONET/SDH network operators might be opening a whole security can of worms by asking for a shift from CLNS management to IP management, but they do want IP comms, hence the current ITU-T activity in the area. If you want to manage the routers with CLNS tools, then, all of the routers in the area have to be dual, and therefore all of them will be sending ISH anyway, so this whole discussion is irrelevant to this particular scenario. Unless.... unless you want to cheat and break the topological rules of RFC 1195. You might do this if you think that CLNP will never get routed to a particular bit of your IS-IS area, then, you might cheat and actually put an IP-only router there. It might not send ISHs, and so the neighbouring dual router had better accept IIH in lieu of the ISHs. Philip > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: 15 February 2002 15:29 > To: Dave Katz > Cc: Christian, Philip [HAL02:GI50:EXCH]; isis-wg@spider.juniper.net > Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH > > > > Dave, how does an IP-only IS form an adjacency with an > > OSI-ES over a PtP > > link if it does not use the ESIS protocol (other than > the use of static > > routes which are always present)? Remember, these are very > > specific cases we > > are talking about here with use of an OSI-ES in this > scenario. I am not > > saying that there are not other methods of accomplishing > this same > > capability through use of different mechanisms. > > > > It doesn't. Why would it? It's an IP host with default route > > pointing at the point-to-point link, or if you're really lucky it is > > smart enough to listen to the router discovery protocol. The fact > > that it speaks OSI takes up memory in the system but is otherwise > > interesting. The router by definition won't forward its > CLNP packets > > anyhow. There are well-known IP mechanisms for accomplishing this > > stuff. > > OK! Just one final point and then I'll stop my crusade. > > I realize that given today's technological advances in the IP > arena, this > makes no sense. But, given the time and need, this sort of > configuration did > make sense. A DECnet Phase V ES possesses the capabilities to > transport its > data via CLNP and/or IP. Given that scenario and the fact > that one of the > first Integrated IS-IS routers released was OSI based and not > IP based, > would it not make sense to possess the above capabilities for remote > management purposes. Especially if you had a mix of OSI and > IP based IS > routers in your network domain. > > Dave, I am not trying to create a stink here! I am simply > trying to point > out some network configurations (tier 1, large enterprise and > significantly > complex and large banking networks) I am very familiar with > that have used > this mechanism for remote management in the past. > > I believe fixing something which (IMHO) is not broken can lead to > limitations in the protocol which may impact a particular > customer's ability > to upgrade with out reconfiguring their entire network management > infrastructure. Of course, there is the other side to this > coin, how long do > we provide backward compatibility for networks which MAY be out dated? > > OK, time to fade away... :^) > > Cheers, > Ken Larmer > CommSense Networks > > ------_=_NextPart_001_01C1B638.79F9EA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Question on the usage of ISH and P2PIIH

Ahh! I think that I know what Ken means.

I think that the suggestion is that if you have dual = routers (IP and CLNP), then, why not manage them using OSI based = management tools, instead of IP ones.

The advantage would be that it would be hard to hack = them as CLNP doesn't get routed by the Internet, and know-one out there = has the tools.

Security by obscurity!

I too have been thinking that SONET/SDH network = operators might be opening a whole security can of worms by asking for = a shift from CLNS management to IP management, but they do want IP = comms, hence the current ITU-T activity in the area.

If you want to manage the routers with CLNS tools, = then, all of the routers in the area have to be dual, and therefore all = of them will be sending ISH anyway, so this whole discussion is = irrelevant to this particular scenario.

Unless.... unless you want to cheat and break the = topological rules of RFC 1195.  You might do this if you think = that CLNP will never get routed to a particular bit of your IS-IS area, = then, you might cheat and actually put an IP-only router there.  = It might not send ISHs, and so the neighbouring dual router had better = accept IIH in lieu of the ISHs.

Philip

> -----Original Message-----
> From: Ken Larmer [mailto:Larmer@CommSense.Net]
> Sent: 15 February 2002 15:29
> To: Dave Katz
> Cc: Christian, Philip [HAL02:GI50:EXCH]; = isis-wg@spider.juniper.net
> Subject: RE: [Isis-wg] Question on the usage of = ISH and P2PIIH
>
>
> >        Dave, how = does an IP-only IS form an adjacency with an
> > OSI-ES over a PtP
> >    link if it does not use = the ESIS protocol (other than
> the use of static
> >    routes which are always = present)? Remember, these are very
> > specific cases we
> >    are talking about here = with use of an OSI-ES in this
> scenario. I am not
> >    saying that there are = not other methods of accomplishing
> this same
> >    capability through use = of different mechanisms.
> >
> > It doesn't.  Why would it?  It's = an IP host with default route
> > pointing at the point-to-point link, or if = you're really lucky it is
> > smart enough to listen to the router = discovery protocol.  The fact
> > that it speaks OSI takes up memory in the = system but is otherwise
> > interesting.  The router by = definition won't forward its
> CLNP packets
> > anyhow.  There are well-known IP = mechanisms for accomplishing this
> > stuff.
>
> OK! Just one final point and then I'll stop my = crusade.
>
> I realize that given today's technological = advances in the IP
> arena, this
> makes no sense. But, given the time and need, = this sort of
> configuration did
> make sense. A DECnet Phase V ES possesses the = capabilities to
> transport its
> data via CLNP and/or IP. Given that scenario = and the fact
> that one of the
> first Integrated IS-IS routers released was OSI = based and not
> IP based,
> would it not make sense to possess the above = capabilities for remote
> management purposes. Especially if you had a = mix of OSI and
> IP based IS
> routers in your network domain.
>
> Dave, I am not trying to create a stink here! I = am simply
> trying to point
> out some network configurations (tier 1, large = enterprise and
> significantly
> complex and large banking networks) I am very = familiar with
> that have used
> this mechanism for remote management in the = past.
>
> I believe fixing something which (IMHO) is not = broken can lead to
> limitations in the protocol which may impact a = particular
> customer's ability
> to upgrade with out reconfiguring their entire = network management
> infrastructure. Of course, there is the other = side to this
> coin, how long do
> we provide backward compatibility for networks = which MAY be out dated?
>
> OK, time to fade away... :^)
>
> Cheers,
> Ken Larmer
> CommSense Networks
>
>

------_=_NextPart_001_01C1B638.79F9EA90-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 14:28:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16849 for ; Fri, 15 Feb 2002 14:28:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FJK2L20923; Fri, 15 Feb 2002 11:20:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FJJ7L20908 for ; Fri, 15 Feb 2002 11:19:07 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Koen Vermeulen'" Cc: Isis-wg Subject: RE: [Isis-wg] Regarding draft-ietf-isis-wg-mib-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Feb 2002 14:24:23 -0500 > Don't we also need an 'extended local circuit id' (used for > creating point-to-point '3-way handshake' ajacencies) for > point-to-point circuits? > Koen - Won't isisCircIfIndex meet your needs for a unique ID? I think at one point I had a distinct 3-way-ID thing, but all you need is a unique ID, and IfIndex should do that. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 14:39:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17358 for ; Fri, 15 Feb 2002 14:39:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FJW1L21000; Fri, 15 Feb 2002 11:32:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1DF8qL05346 for ; Wed, 13 Feb 2002 07:08:53 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1DFF2F18259; Wed, 13 Feb 2002 10:15:02 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-135.cisco.com [64.102.83.135]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAT31589; Wed, 13 Feb 2002 10:14:43 -0500 (EST) Message-Id: <4.3.2.7.2.20020213093009.03bc9da8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: Jeff Learman Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: Tony Przygienda , Micah Bartell , Les Ginsberg , "'Tony Li'" , Ken Larmer , Shankar Vemulapalli , "Chan, Chung Ming" , isis-wg@spider.juniper.net, "'Alex Zinin'" In-Reply-To: <4103264BC8D3D51180B7002048400C450714F2@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3942168==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Feb 2002 10:13:35 -0500 --=====================_3942168==_.ALT Content-Type: text/plain; charset="us-ascii" At 07:43 AM 2/13/2002, Philip Christian wrote: >So I have been thinking a little about the wording of a document to describe the situation/history with ISHs and to mandate that an implementation must be able to cope with ISHs or lack of ISHs. > >I have hit a problem. > >I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH. Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting? First of all, I think it would be best to create an informational RFC, alerting implementors to common practice. That way, we avoid legal vs. illegal, and simply describe behavior that an implementation is recommended to be able to interoperate with. In this way, we can point out different interpretations of the spec, which is helpful to implementors without creating a new spec and new contradictions. Whether an informational RFC should contain a number of items or whether there should be one per issue I leave to the others to hash out -- evidently it's been hashed out a bit already. I can see pros and cons on both sides of that issue. >According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:- > >1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway. I agree, and therefore don't think it's necessary to specify anything. We should focus on observable behavior, not internal models. It's hard to write a good spec without an internal model, so I'm not criticizing 10589 here. But in this case, we don't need to exacerbate the problems caused by specifying an internal model, we can just talk about behavior. The hard work has already been done. >2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout? I assume that implementations that don't send ISH PDUs also don't wait for a timer to expire, they just send the IIH when the circuit comes up, so the adjacency would come up right away in either case. Note that 10589:1992 says to send the IIH when the circuit is first enabled; only 10589:1992+TC1:1993 says to wait to receive an ISH. Some implementations don't follow TC1, which clearly says when to send the ISH. Prior to that, there's only the implication that you wait to send an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1). >The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason. I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects. It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour. What am I missing here? Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs? The only real purpose of the ISH is in case the system at the other end supports CLNP but is not running IS-IS, such as when it's an ES. Assuming the OSI router's NSAP matches its NET (except for NSEL), then its network service users are reachable without doing anything special. Admittedly, according to rule changes in TC1:1993, the ISH also serves the purpose of starting the process to bring up the adjacency. But this is unnecessary. The only information in the ISH that is pertinent is "I'm a router!" By the way, the ISH is neither necessary nor sufficient for handling network service users on the OSI router, which is very important but was ignored in a lot of the early OSI standards. There are two cases: (a) all NSAPs for the network service user matches the NET (except for NSEL), and (b) there are NSAPs that don't match the NET. Case (a) is naturally handled by IS-IS, and the ISH isn't needed. Case (b) isn't covered in IS-IS, and you can't use ISH PDUs to solve it -- because the ISH can only contain one NET, and it has to match the adjacency so you can't just send a bunch of them. This was resolved for SONET NEs by the SIF; the router should advertise these as ES neighbors with path costs of 1. (I argued for zero, but that didn't go over because it might have caused trouble with implementations that couldn't handle zero metrics anywhere outside pseudonode LSPs.) Hopefully we don't need to go into that in an RFC! >Sorry for so many questions. Sorry for such long answers ;-) >Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed. I think the thing to do is to state that prevalent implementations do not send ISHs on PTP links, and that an implementation is advised to bring up the adjacency anyway. To do this, we must relax the rule in 10589:1992+TC1:1993 that does not permit sending an IIH until an ISH has been received, and allow sending of the IIH when an IIH has been received, or for systems where connections to OSI end systems over PTP links are not supported, the IIH can be sent as soon as the link is up. I also think it may be appropriate to include a little history here, showing how 19589:1992 could reasonably be interpreted to allow sending IIHs before receiving ISHs, yet the rule in TC1 would not interoperate with this interpretation. (I think that TC1, while well-intentioned, was unfortunately misworded. It should have allowed sending an IIH after receiving one.) Regards, Jeff >Thoughts? > >Philip --=====================_3942168==_.ALT Content-Type: text/html; charset="us-ascii" At 07:43 AM 2/13/2002, Philip Christian wrote:

So I have been thinking a little about the wording of a document to describe the situation/history with ISHs and to mandate that an implementation must be able to cope with ISHs or lack of ISHs.

I have hit a problem.

I assume that there are implementations out there that simply totally ignore incoming ISHs, and actually do nothing until they receive an IIH.  Would this be considerred legal or illegal behaviour in the doc that I am thinking of drafting?

First of all, I think it would be best to create an informational
RFC, alerting implementors to common practice.  That way, we avoid
legal vs. illegal, and simply describe behavior that an implementation
is recommended to be able to interoperate with.  In this way, we can
point out different interpretations of the spec, which is helpful
to implementors without creating a new spec and new contradictions.

Whether an informational RFC should contain a number of items or
whether there should be one per issue I leave to the others to hash
out -- evidently it's been hashed out a bit already.  I can see
pros and cons on both sides of that issue.

According to 10589 the action on receipt of an ISH is that a new adjacency is created with adjacencyState "Initialising" and an IIH PDU is sent. As the IIH would be sent anyway whenever ISISHelloTimer expires, then there are maybe two consequences:-

1. The adjacency going to "Initialising", which one could argue is a non-event, as an adjacency that is "Initialising" cannot be used for anything, and the state will be ignored when an IIH finally comes along anyway.

I agree, and therefore don't think it's necessary to specify anything.
We should focus on observable behavior, not internal models.  It's hard
to write a good spec without an internal model, so I'm not criticizing
10589 here.  But in this case, we don't need to exacerbate the problems
caused by specifying an internal model, we can just talk about behavior.
The hard work has already been done.

2. Does it mean that the adjacency might come up faster as it doesn't have to wait for a ISISHelloTimer to timeout?

I assume that implementations that don't send ISH PDUs also don't wait
for a timer to expire, they just send the IIH when the circuit comes up,
so the adjacency would come up right away in either case.  Note that
10589:1992 says to send the IIH when the circuit is first enabled;
only 10589:1992+TC1:1993 says to wait to receive an ISH.  Some
implementations don't follow TC1, which clearly says when to send the
ISH.  Prior to that, there's only the implication that you wait to send
an IIH (in 8.2.3-c, renumbered to 8.2.4-c by TC1).

The only other use for ISH seems to be if a router wants to act as an OSI End-System for some reason.  I haven't quite figured out why/when/if an OSI router needs to also have End-System functionality, unless it is something to do with OSI redirects.  It would seem to me that if a router needs to have ES functionality is could attach it to itself rather than to its neighbour.  What am I missing here?  Why can't you have an OSI router that is only an IS, and, if so why does it need to worry about ISHs?

The only real purpose of the ISH is in case the system at the other end
supports CLNP but is not running IS-IS, such as when it's an ES.  Assuming
the OSI router's NSAP matches its NET (except for NSEL), then its network
service users are reachable without doing anything special.  Admittedly,
according to rule changes in TC1:1993, the ISH also serves the purpose of
starting the process to bring up the adjacency.  But this is unnecessary.
The only information in the ISH that is pertinent is "I'm a router!"

By the way, the ISH is neither necessary nor sufficient for handling
network service users on the OSI router, which is very important but
was ignored in a lot of the early OSI standards.  There are two cases:
(a) all NSAPs for the network service user matches the NET (except for
NSEL), and (b) there are NSAPs that don't match the NET.  Case (a) is
naturally handled by IS-IS, and the ISH isn't needed.  Case (b) isn't
covered in IS-IS, and you can't use ISH PDUs to solve it -- because
the ISH can only contain one NET, and it has to match the adjacency
so you can't just send a bunch of them.  This was resolved for SONET
NEs by the SIF; the router should advertise these as ES neighbors with
path costs of 1.  (I argued for zero, but that didn't go over because it
might have caused trouble with implementations that couldn't handle
zero metrics anywhere outside pseudonode LSPs.)  Hopefully we don't need
to go into that in an RFC!

Sorry for so many questions.

Sorry for such long answers ;-)


Anyhow, we are going to have a choice; either we say that it is OK to just ignore incoming ISHs, or we say that we must work if they are not there but if they are then they must be processed.

I think the thing to do is to state that prevalent implementations
do not send ISHs on PTP links, and that an implementation is advised to
bring up the adjacency anyway.  To do this, we must relax the rule in 10589:1992+TC1:1993 that does not permit sending an IIH until an ISH
has been received, and allow sending of the IIH when an IIH has been
received, or for systems where connections to OSI end systems over
PTP links are not supported, the IIH can be sent as soon as the link
is up.

I also think it may be appropriate to include a little history here,
showing how 19589:1992 could reasonably be interpreted to allow
sending IIHs before receiving ISHs, yet the rule in TC1 would not
interoperate with this interpretation.  (I think that TC1, while
well-intentioned, was unfortunately misworded.  It should have
allowed sending an IIH after receiving one.)

Regards,
Jeff

Thoughts?

Philip
--=====================_3942168==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Feb 15 14:40:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17392 for ; Fri, 15 Feb 2002 14:40:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1FJWPL21016; Fri, 15 Feb 2002 11:32:25 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ghostrider.gredler.at (ghostrider.gredler.at [193.83.223.228]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1EDMFL12669 for ; Thu, 14 Feb 2002 05:22:15 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id OAA23801 for isis-wg@spider.juniper.net; Thu, 14 Feb 2002 14:28:20 +0100 From: Hannes Gredler To: isis-wg@spider.juniper.net Message-ID: <20020214142820.A23789@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Isis-wg] draft-ietf-isis-gmpls-extensions-08.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 14:28:20 +0100 [ ... ] 5.3. Link Protection Type The Link Protection Type is is a sub-TLV (of type 20) of the extended IS reachability TLV, with length two octets, the first of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ which is a bit vector describing the protection capabilities of the link. They are: 0x01 Extra Traffic 0x02 Unprotected 0x04 Shared 0x08 Dedicated 1:1 0x10 Dedicated 1+1 0x20 Enhanced 0x40 Reserved 0x80 Reserved 5.4. Interface Switching Capability Descriptor [ ... ] --- what happened to the second octet ? /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Feb 17 09:32:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06304 for ; Sun, 17 Feb 2002 09:32:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1HEM2L34140; Sun, 17 Feb 2002 06:22:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1HELcL34128 for ; Sun, 17 Feb 2002 06:21:38 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1HESKD04562; Sun, 17 Feb 2002 09:28:20 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-192.cisco.com [10.82.240.192]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAU07592; Sun, 17 Feb 2002 09:28:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020217091902.01d5c660@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH Cc: isis-wg@spider.juniper.net In-Reply-To: References: <200202142117.g1ELH7h31422@cirrus.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 17 Feb 2002 09:27:56 -0500 Ken, We're not disagreeing with the scenario or motivation. But if you have an IP-only IS-IS router connected to an IP end system that supports CLNP/IP tunneling (that's the scenario, right?) then the ISH sent by the IS-IS router does NOT help CLNP on the ES in any way at all. In fact, it could easily confuse the CLNP ES into thinking that the IS-IS router was a CLNP router, which it is not. From that point of view, it would be far better for an IP-only router NOT to send an ISH. Kapish? By the way, don't back off until we understand one another. Then, if we still disagree, that's another thing. But your reply and your earlier email say that the ISH emitted by an IP-only router helps a CLNP ES, and it most definitely does not; it is more likely to cause confusion. This is not a case of breaking something that works. If there are CLNP/IP ESs that interoperate with IP-only IS-IS routers, they should continue to work even if the IS-IS router doesn't send an ISH. If it did break such an implementation, that implementation is misinterpreting the ISH. If you want, we can take this discussion off-line. I've done a bit of work in this very area. Jeff At 10:28 AM 2/15/2002, you wrote: >> Dave, how does an IP-only IS form an adjacency with an >> OSI-ES over a PtP >> link if it does not use the ESIS protocol (other than the use of static >> routes which are always present)? Remember, these are very >> specific cases we >> are talking about here with use of an OSI-ES in this scenario. I am not >> saying that there are not other methods of accomplishing this same >> capability through use of different mechanisms. >> >> It doesn't. Why would it? It's an IP host with default route >> pointing at the point-to-point link, or if you're really lucky it is >> smart enough to listen to the router discovery protocol. The fact >> that it speaks OSI takes up memory in the system but is otherwise >> interesting. The router by definition won't forward its CLNP packets >> anyhow. There are well-known IP mechanisms for accomplishing this >> stuff. > >OK! Just one final point and then I'll stop my crusade. > >I realize that given today's technological advances in the IP arena, this >makes no sense. But, given the time and need, this sort of configuration did >make sense. A DECnet Phase V ES possesses the capabilities to transport its >data via CLNP and/or IP. Given that scenario and the fact that one of the >first Integrated IS-IS routers released was OSI based and not IP based, >would it not make sense to possess the above capabilities for remote >management purposes. Especially if you had a mix of OSI and IP based IS >routers in your network domain. > >Dave, I am not trying to create a stink here! I am simply trying to point >out some network configurations (tier 1, large enterprise and significantly >complex and large banking networks) I am very familiar with that have used >this mechanism for remote management in the past. > >I believe fixing something which (IMHO) is not broken can lead to >limitations in the protocol which may impact a particular customer's ability >to upgrade with out reconfiguring their entire network management >infrastructure. Of course, there is the other side to this coin, how long do >we provide backward compatibility for networks which MAY be out dated? > >OK, time to fade away... :^) > >Cheers, >Ken Larmer >CommSense Networks > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 18 06:06:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00081 for ; Mon, 18 Feb 2002 06:06:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1IAv2L39017; Mon, 18 Feb 2002 02:57:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1IAujL39005 for ; Mon, 18 Feb 2002 02:56:46 -0800 (PST) (envelope-from koen.vermeulen@alcatel.be) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g1IB25n15209; Mon, 18 Feb 2002 12:02:06 +0100 (MET) Message-ID: <3C70DEEF.B105A14A@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: Isis-wg Subject: Re: [Isis-wg] Regarding draft-ietf-isis-wg-mib-07.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 12:01:03 +0100 Content-Transfer-Encoding: 7bit Hello Jeff, Good idea. That will do for me. Thanks, Koen Jeff Parker wrote: > > > Don't we also need an 'extended local circuit id' (used for > > creating point-to-point '3-way handshake' ajacencies) for > > point-to-point circuits? > > > > Koen - > Won't isisCircIfIndex meet your needs for a unique > ID? I think at one point I had a distinct 3-way-ID thing, > but all you need is a unique ID, and IfIndex should do > that. > > - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 18 09:19:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03386 for ; Mon, 18 Feb 2002 09:19:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1IEA5L40336; Mon, 18 Feb 2002 06:10:05 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web11205.mail.yahoo.com (web11205.mail.yahoo.com [216.136.131.187]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g1IE4fL40300 for ; Mon, 18 Feb 2002 06:04:41 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Message-ID: <20020218141113.74097.qmail@web11205.mail.yahoo.com> Received: from [203.196.145.150] by web11205.mail.yahoo.com via HTTP; Mon, 18 Feb 2002 06:11:13 PST From: Aravind Ravikumar To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-764236013-1014041473=:72494" Subject: [Isis-wg] doubt regarding acknowledgement on broadcast circuits Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 06:11:13 -0800 (PST) --0-764236013-1014041473=:72494 Content-Type: text/plain; charset=us-ascii Hi All, According to the section 7.3.16.4 (LSP expiration synchronisation) of ISO 10589 we have to send an acknowledgement even on broadcast circuit in the following case: If an LSP from source S with zero Remaining Lifetime is received on circuit C : a) If no LSP from S is in memory, then the IS shall 1) send an acknowledgement of the LSP on circuit C, but 2) shall not retain the LSP after the acknowledgement has been sent. But I am not clear about the purpose of sending acknowldgement on a broadcast circuit. Because the transmitter of the LSP is not waiting for any acknowledgement and would have already reset its SRM flag for that particular circuit. Am I right or wrong, please help me. Thanks in advance. --------------------------------- Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games --0-764236013-1014041473=:72494 Content-Type: text/html; charset=us-ascii

Hi All,

According to the section 7.3.16.4 (LSP expiration synchronisation) of ISO 10589
we have to send an acknowledgement even on broadcast circuit in the following case:

If an LSP from source S with zero Remaining Lifetime is received
on circuit C :
a) If no LSP from S is in memory, then the IS shall
1) send an acknowledgement of the LSP on circuit C, but
2) shall not retain the LSP after the acknowledgement has been sent.

But I am not clear about the purpose of sending acknowldgement on a broadcast
circuit. Because the transmitter of the LSP is not waiting for any acknowledgement
and would have already reset its SRM flag for that particular circuit.

Am I right or wrong, please help me.

Thanks in advance.


Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games --0-764236013-1014041473=:72494-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 18 13:13:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12135 for ; Mon, 18 Feb 2002 13:13:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1II51L41371; Mon, 18 Feb 2002 10:05:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1II4wL41356 for ; Mon, 18 Feb 2002 10:04:58 -0800 (PST) (envelope-from ajeetgandhi@yahoo.com) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g1IIBVc37663 for ; Mon, 18 Feb 2002 10:11:31 -0800 (PST) X-JNPR-Received-From: outside Received: from web20106.mail.yahoo.com ([216.136.226.43]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 10:04:10 -0800 Message-ID: <20020218180507.29458.qmail@web20106.mail.yahoo.com> Received: from [63.113.148.3] by web20106.mail.yahoo.com via HTTP; Mon, 18 Feb 2002 10:05:07 PST From: A Gandhi To: dkatz@juniper.net Cc: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 18 Feb 2002 18:04:10.0734 (UTC) FILETIME=[AA7AC8E0:01C1B8A6] Subject: [Isis-wg] ISIS as PE-CE protocol for BGP/MPLS VPNs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 10:05:07 -0800 (PST) Dave, I have noticed considerable interest in the IETF community and among vendors towards BGP/MPLS VPNs (RFC 2547) using OSPF as the PE-CE protocol. draft-rosen-vpns-ospf-bgp-mpls-04 is also defined. Are the ISPs showing any interest in using ISIS as the PE-CE protocol, as it is the IGP of choice for many large ISPs. Further, is someone in isis-wg working in this direction? Thanks in advance for you comments. Ajeet Gandhi __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 18 17:24:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20926 for ; Mon, 18 Feb 2002 17:24:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1IMG1L42414; Mon, 18 Feb 2002 14:16:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1IMFIL42402 for ; Mon, 18 Feb 2002 14:15:18 -0800 (PST) (envelope-from Ming.Chan@SpirentCom.COM) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.10.2+Sun/8.10.2) with ESMTP id g1IMLmf28514 for ; Mon, 18 Feb 2002 12:21:51 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 12:27:50 -1000 Message-ID: <8AC36D3167EED41184C800508BD9540502DD67A8@apollo.adtech-inc.com> From: "Chan, Chung Ming" To: "'isis-wg@spider.juniper.net'" Cc: "Chan, Chung Ming" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Isis-wg] Number of P2P IIH required to bring a p2p link to Up state Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 12:27:42 -1000 Hi, The question that I've is as following: On the p2p link of an IS (assuming it is IP-Only and does not rely on ISH for the purpose of bring up the adj. and 3-way handshake is NOT used here), if the link just comes up and the IS is sending out P2P IIHs and now the IS receives a VALID P2P IIH, shouldn't the IS goes to Up state right the way according to ISO/IEC 10589, Section 8.2.5? We've an implementation in our Lab that requires three P2P IIHs to bring it to up state and it means that it requires 3 Hello-times to bring the Adj. Up once it is in down state. In other words, shouldn't an implementation require only one P2PIIH to bring it to Up state as implicitly stated in the state tables in Section 8.2.5? Thanks, Ming Chan _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 18 22:09:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28676 for ; Mon, 18 Feb 2002 22:09:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J311L43585; Mon, 18 Feb 2002 19:01:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J30nL43573 for ; Mon, 18 Feb 2002 19:00:49 -0800 (PST) (envelope-from danny@dog.tcb.net) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g1J37Pc46839 for ; Mon, 18 Feb 2002 19:07:25 -0800 (PST) X-JNPR-Received-From: outside Received: from tcb.net ([205.168.100.1]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 18:57:41 -0800 Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g1J2mmn20521 for ; Mon, 18 Feb 2002 19:48:48 -0700 Message-Id: <200202190248.g1J2mmn20521@tcb.net> To: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] ISIS as PE-CE protocol for BGP/MPLS VPNs X-OriginalArrivalTime: 19 Feb 2002 02:57:41.0765 (UTC) FILETIME=[328A7B50:01C1B8F1] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 19:48:48 -0700 The BGP/MPLS VPN OSPF PE-CE stuff is being proposed to address the issue of destination reachability (i.e., route) carriage between *enterprises*. That being the case, and very few (if any?) enterprises employing IS-IS, I'm guessing it's unlikely there's much interest in IS-IS PE-CE work. Of course, it wouldn't be incredibly surprising given .. the amount of attention 2547 attracts these days. -danny > I have noticed considerable interest in the IETF > community and among vendors towards BGP/MPLS VPNs (RFC > 2547) using OSPF as the PE-CE protocol. > draft-rosen-vpns-ospf-bgp-mpls-04 is also defined. Are > the ISPs showing any interest in using ISIS as the > PE-CE protocol, as it is the IGP of choice for many > large ISPs. Further, is someone in isis-wg working in > this direction? _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 18 22:46:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00246 for ; Mon, 18 Feb 2002 22:46:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J3c2L43776; Mon, 18 Feb 2002 19:38:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J3bNL43764 for ; Mon, 18 Feb 2002 19:37:23 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA24433; Mon, 18 Feb 2002 19:43:57 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 19:43:57 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F7F1@avalon.pluris.com> From: Les Ginsberg To: "'Aravind Ravikumar'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] doubt regarding acknowledgement on broadcast circui ts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8F7.A8B56E60" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 19:43:56 -0800 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_01C1B8F7.A8B56E60 Content-Type: text/plain; charset="iso-8859-1" The spec is less clear than it might be in this regard. You are correct that if C is a broadcast circuit no PSNP should be sent in this case. Better wording - and more consistent with the wording in other sections would be: 1)If C is a non-broadcast circuit, set SSNflag for that LSP for C 2) shall not retain the LSP after the acknowledgement has been sent Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, February 18, 2002 6:11 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] doubt regarding acknowledgement on broadcast circuits Hi All, According to the section 7.3.16.4 (LSP expiration synchronisation) of ISO 10589 we have to send an acknowledgement even on broadcast circuit in the following case: If an LSP from source S with zero Remaining Lifetime is received on circuit C : a) If no LSP from S is in memory, then the IS shall 1) send an acknowledgement of the LSP on circuit C, but 2) shall not retain the LSP after the acknowledgement has been sent. But I am not clear about the purpose of sending acknowldgement on a broadcast circuit. Because the transmitter of the LSP is not waiting for any acknowledgement and would have already reset its SRM flag for that particular circuit. Am I right or wrong, please help me. Thanks in advance. _____ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games ------_=_NextPart_001_01C1B8F7.A8B56E60 Content-Type: text/html; charset="iso-8859-1"
The spec is less clear than it might be in this regard. You are correct that if C is a broadcast circuit no PSNP should be sent in this case. Better wording - and more consistent with the wording in other sections would be:
 
   1)If C is a non-broadcast circuit, set SSNflag for that LSP for C
   2) shall not retain the LSP after the acknowledgement has been sent
 
   Les
 
 
-----Original Message-----
From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com]
Sent: Monday, February 18, 2002 6:11 AM
To: isis-wg@spider.juniper.net
Subject: [Isis-wg] doubt regarding acknowledgement on broadcast circuits

Hi All,

According to the section 7.3.16.4 (LSP expiration synchronisation) of ISO 10589
we have to send an acknowledgement even on broadcast circuit in the following case:

If an LSP from source S with zero Remaining Lifetime is received
on circuit C :
a) If no LSP from S is in memory, then the IS shall
1) send an acknowledgement of the LSP on circuit C, but
2) shall not retain the LSP after the acknowledgement has been sent.

But I am not clear about the purpose of sending acknowldgement on a broadcast
circuit. Because the transmitter of the LSP is not waiting for any acknowledgement
and would have already reset its SRM flag for that particular circuit.

Am I right or wrong, please help me.

Thanks in advance.


Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
------_=_NextPart_001_01C1B8F7.A8B56E60-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Feb 18 23:55:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01589 for ; Mon, 18 Feb 2002 23:55:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J4l1L44073; Mon, 18 Feb 2002 20:47:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J4kpL44061 for ; Mon, 18 Feb 2002 20:46:51 -0800 (PST) (envelope-from ajeetgandhi@yahoo.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id g1J4rRc48204 for ; Mon, 18 Feb 2002 20:53:27 -0800 (PST) X-JNPR-Received-From: outside Received: from web20106.mail.yahoo.com ([216.136.226.43]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Feb 2002 20:44:03 -0800 Message-ID: <20020219044501.1229.qmail@web20106.mail.yahoo.com> Received: from [63.113.148.3] by web20106.mail.yahoo.com via HTTP; Mon, 18 Feb 2002 20:45:01 PST From: A Gandhi Subject: Re: [Isis-wg] ISIS as PE-CE protocol for BGP/MPLS VPNs To: danny@tcb.net, isis-wg@juniper.net In-Reply-To: <200202190248.g1J2mmn20521@tcb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 19 Feb 2002 04:44:03.0655 (UTC) FILETIME=[0E719D70:01C1B900] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 20:45:01 -0800 (PST) I agree that enterprises seldom use IS-IS, but what about a BGP/MPLS VPN provider whose customers are ISPs. For example, a Tier 1 ISP could be providing BGP/MPLS VPN service to a Tier 2 ISP. This Tier 2 ISP could very well be using IS-IS. Thanks. Ajeet --- Danny McPherson wrote: > > The BGP/MPLS VPN OSPF PE-CE stuff is being proposed > to > address the issue of destination reachability (i.e., > route) carriage between *enterprises*. That being > the > case, and very few (if any?) enterprises employing > IS-IS, > I'm guessing it's unlikely there's much interest in > IS-IS PE-CE work. > > Of course, it wouldn't be incredibly surprising > given > .. the amount of attention 2547 attracts these days. > > > -danny > > > > I have noticed considerable interest in the IETF > > community and among vendors towards BGP/MPLS VPNs > (RFC > > 2547) using OSPF as the PE-CE protocol. > > draft-rosen-vpns-ospf-bgp-mpls-04 is also defined. > Are > > the ISPs showing any interest in using ISIS as the > > PE-CE protocol, as it is the IGP of choice for > many > > large ISPs. Further, is someone in isis-wg working > in > > this direction? > _______________________________________________ > Isis-wg mailing list - > Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 19 00:26:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02220 for ; Tue, 19 Feb 2002 00:26:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J5I1L44234; Mon, 18 Feb 2002 21:18:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web21309.mail.yahoo.com (web21309.mail.yahoo.com [216.136.173.254]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g1J5HLL44222 for ; Mon, 18 Feb 2002 21:17:21 -0800 (PST) (envelope-from shyama3in2002@yahoo.com) Message-ID: <20020219052356.19374.qmail@web21309.mail.yahoo.com> Received: from [203.197.142.162] by web21309.mail.yahoo.com via HTTP; Mon, 18 Feb 2002 21:23:56 PST From: shyama sai To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] Beginner's question Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Feb 2002 21:23:56 -0800 (PST) Hi, I am new to IS-IS protocol implementation. I would want to know what are the authentic material for referring to IS-IS.ISO 10589 is not freely downloadable. But I found an RFC (RFC 1142) which is a republication of ISO 10589. Is it good enough? And for Dual IS-IS, I found RFC 1195. This RFC outlines the extra implementation specifics for supporting IS-IS over TCP/IP stack. What should I refer to get to know the basics of IS-IS thoroughly? rgds shyama __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 19 01:23:09 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02888 for ; Tue, 19 Feb 2002 01:23:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J6E2L44483; Mon, 18 Feb 2002 22:14:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from nycsmtp2out.rdc-nyc.rr.com (nycsmtp2out.rdc-nyc.rr.com [24.29.99.227]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1J6DXL44471 for ; Mon, 18 Feb 2002 22:13:33 -0800 (PST) (envelope-from kcullimo@nyc.rr.com) Received: from reelyfayst (24-90-68-231.nyc.rr.com [24.90.68.231]) by nycsmtp2out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with SMTP id g1J6IkjW002936 for ; Tue, 19 Feb 2002 01:18:46 -0500 (EST) Message-ID: <019b01c1b90d$b38732e0$e7445a18@damnitsfast.local> From: "Kevin Cullimore" To: References: <20020219052356.19374.qmail@web21309.mail.yahoo.com> Subject: Re: [Isis-wg] Beginner's question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Feb 2002 01:21:43 -0500 Content-Transfer-Encoding: 7bit I'm not sure how up to date this link is http://www.helios-is.com/downloads/iso/ Regards, Kevin ----- Original Message ----- From: "shyama sai" To: Sent: Tuesday, February 19, 2002 12:23 AM Subject: [Isis-wg] Beginner's question > Hi, > I am new to IS-IS protocol implementation. I would > want to know what are the authentic material for > referring to IS-IS.ISO 10589 is not freely > downloadable. But I found an RFC (RFC 1142) which is a > republication of ISO 10589. Is it good enough? > > And for Dual IS-IS, I found RFC 1195. This RFC > outlines the extra implementation specifics for > supporting IS-IS over TCP/IP stack. > > What should I refer to get to know the basics of IS-IS > thoroughly? > > rgds > shyama > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 19 09:25:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20430 for ; Tue, 19 Feb 2002 09:25:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1JEG2L46834; Tue, 19 Feb 2002 06:16:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web11204.mail.yahoo.com (web11204.mail.yahoo.com [216.136.131.186]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g1JEFCL46822 for ; Tue, 19 Feb 2002 06:15:12 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Message-ID: <20020219142150.59169.qmail@web11204.mail.yahoo.com> Received: from [203.196.145.150] by web11204.mail.yahoo.com via HTTP; Tue, 19 Feb 2002 06:21:50 PST From: Aravind Ravikumar To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-531978824-1014128510=:57408" Subject: [Isis-wg] Area address dropping Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Feb 2002 06:21:50 -0800 (PST) --0-531978824-1014128510=:57408 Content-Type: text/plain; charset=us-ascii Hi All, According to the note 14 section 7.2.11 of ISO 10589(92) we have to retain area addresses advertised by systems in their level 1 LSP whether they are currently reachable or not. Once the number of area addresses reach the configured maximumAreaAddresses we have to drop numerically higher area addresses. I think this can lead to a situation where we retain area addresses from the systems not reachable at all and dropping area addresses from systems which are currently reachable Am I right? Thanx in advanceAravind --------------------------------- Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games --0-531978824-1014128510=:57408 Content-Type: text/html; charset=us-ascii
Hi All,
 
According to the note 14 section 7.2.11 of ISO 10589(92) we have to retain
area addresses advertised by systems in their level 1 LSP whether they are
currently reachable or not. Once the number of area addresses reach the
configured maximumAreaAddresses we have to drop numerically higher area
addresses. I think this can lead to a situation where we retain area addresses from
the systems not reachable at all and dropping area addresses
from systems which are  currently reachable
 
Am I right?
 
Thanx in advance
Aravind


Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games --0-531978824-1014128510=:57408-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 19 12:25:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28268 for ; Tue, 19 Feb 2002 12:25:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1JHG1L47556; Tue, 19 Feb 2002 09:16:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mx3.tellabs.com (mx3.tellabs.com [204.68.180.53]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1JHFFL47544 for ; Tue, 19 Feb 2002 09:15:16 -0800 (PST) (envelope-from jonathan.sadler@tellabs.com) Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx3.tellabs.com (Mirapoint) with ESMTP id AEM32463; Tue, 19 Feb 2002 11:21:53 -0600 (CST) Received: from tellabs.com (dhcp-172-23-111-52.lisle.tellabs.com [172.23.111.52]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id LAA03593; Tue, 19 Feb 2002 11:21:54 -0600 (CST) Message-ID: <3C7289E0.16B41DA4@tellabs.com> From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Cullimore CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Beginner's question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Feb 2002 11:22:40 -0600 Content-Transfer-Encoding: 7bit Or a more authoritive download: http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm Select "Proceed to Public Areas". Jonathan Sadler Kevin Cullimore wrote: > > I'm not sure how up to date this link is > > http://www.helios-is.com/downloads/iso/ > > Regards, > > Kevin > > ----- Original Message ----- > From: "shyama sai" > To: > Sent: Tuesday, February 19, 2002 12:23 AM > Subject: [Isis-wg] Beginner's question > > > Hi, > > I am new to IS-IS protocol implementation. I would > > want to know what are the authentic material for > > referring to IS-IS.ISO 10589 is not freely > > downloadable. But I found an RFC (RFC 1142) which is a > > republication of ISO 10589. Is it good enough? > > > > And for Dual IS-IS, I found RFC 1195. This RFC > > outlines the extra implementation specifics for > > supporting IS-IS over TCP/IP stack. > > > > What should I refer to get to know the basics of IS-IS > > thoroughly? > > > > rgds > > shyama > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Sports - Coverage of the 2002 Olympic Games > > http://sports.yahoo.com > > _______________________________________________ > > 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 ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 19 21:47:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11854 for ; Tue, 19 Feb 2002 21:47:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1K2d1L49770; Tue, 19 Feb 2002 18:39:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1K2cIL49758 for ; Tue, 19 Feb 2002 18:38:18 -0800 (PST) (envelope-from danny@dog.tcb.net) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1K2ixP77742 for ; Tue, 19 Feb 2002 18:44:59 -0800 (PST) X-JNPR-Received-From: outside Received: from tcb.net ([205.168.100.1]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Feb 2002 18:44:00 -0800 Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g1K2Z8d25119 for ; Tue, 19 Feb 2002 19:35:08 -0700 Message-Id: <200202200235.g1K2Z8d25119@tcb.net> To: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] ISIS as PE-CE protocol for BGP/MPLS VPNs X-OriginalArrivalTime: 20 Feb 2002 02:44:00.0218 (UTC) FILETIME=[73461BA0:01C1B9B8] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Feb 2002 19:35:08 -0700 > I agree that enterprises seldom use IS-IS, but what > about a BGP/MPLS VPN provider whose customers are > ISPs. For example, a Tier 1 ISP could be providing > BGP/MPLS VPN service to a Tier 2 ISP. This Tier 2 ISP > could very well be using IS-IS. Then I'd venture a guess that BGP would be the more suitable PE-CE protocol... Esp. when considering effects that inter-domain/external influences could otherwise impose on the enterprise IGP. -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 20 10:12:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03039 for ; Wed, 20 Feb 2002 10:12:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1KF32L53219; Wed, 20 Feb 2002 07:03:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web11201.mail.yahoo.com (web11201.mail.yahoo.com [216.136.131.171]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g1KF2mL53207 for ; Wed, 20 Feb 2002 07:02:48 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Message-ID: <20020220150933.91958.qmail@web11201.mail.yahoo.com> Received: from [203.196.145.150] by web11201.mail.yahoo.com via HTTP; Wed, 20 Feb 2002 07:09:33 PST From: Aravind Ravikumar To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1282868173-1014217773=:89970" Subject: [Isis-wg] updating area address information Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 20 Feb 2002 07:09:33 -0800 (PST) --0-1282868173-1014217773=:89970 Content-Type: text/plain; charset=us-ascii Hi all, According to the section 7.1.5 we have to construct list of area addresses for the area while processing LEVEL1LSPs and include it in LEVEl 2 LSP number 0. So when a system is no longer advertising an area address which it has advertised earlier, shouldn't we remove that area address from our list and regenerate LEVEL2 LSP number 0? Similarly when the LSP in which an area was advertised ages out shouldn't we remove the area address that we learned from that LSP and regenerate LEVEL2 LSP number 0? But note 14 of section 7.2.11 says that we have to keep area addresses advertised by systems without considering whether they are currently reachable or not Why should we keep it? Since we restrict the number of area addresses shouldn't we ensure that what we are keeping is only uptodate information? please help Thanks in advance Aravind --------------------------------- Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games --0-1282868173-1014217773=:89970 Content-Type: text/html; charset=us-ascii
Hi all,
 
According to the section 7.1.5
we have to construct list of area addresses for the area while processing LEVEL1
LSPs and include it in LEVEl 2 LSP number 0.
 
So when a system is no longer advertising an area address which it has advertised
earlier, shouldn't we remove that area address from our list and regenerate
LEVEL2 LSP number 0?
 
Similarly when the LSP in which an area was advertised  ages out
shouldn't we remove the area address that we learned from that LSP and regenerate
LEVEL2 LSP number 0?
 

But note 14 of section 7.2.11 says that we have to keep area addresses advertised
by systems without considering whether they are currently reachable or not
 
Why should we keep it? Since we restrict the number of area addresses shouldn't we
ensure that what we are keeping is only uptodate information?
 
please help
Thanks in advance
Aravind


Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games --0-1282868173-1014217773=:89970-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 21 04:30:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11855 for ; Thu, 21 Feb 2002 04:30:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1L9L1L57891; Thu, 21 Feb 2002 01:21:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from web21308.mail.yahoo.com (web21308.mail.yahoo.com [216.136.128.174]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g1L9KOL57879 for ; Thu, 21 Feb 2002 01:20:24 -0800 (PST) (envelope-from shyama3in2002@yahoo.com) Message-ID: <20020221092711.39682.qmail@web21308.mail.yahoo.com> Received: from [203.197.142.162] by web21308.mail.yahoo.com via HTTP; Thu, 21 Feb 2002 01:27:11 PST From: shyama sai To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] Metric of Reachable L1 areas in L2 LSP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 01:27:11 -0800 (PST) Hi, In level 2 LSP, when L1 Area addresses are advertised, what is the metric assigned for each of the reachable question? rgds shyama __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 26 07:08:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24850 for ; Tue, 26 Feb 2002 07:08:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1QBt1L91561; Tue, 26 Feb 2002 03:55:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1QBsLL91546 for ; Tue, 26 Feb 2002 03:54:33 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g1QC1cp69305 for ; Tue, 26 Feb 2002 04:01:43 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 04:00:33 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23766; Tue, 26 Feb 2002 07:01:35 -0500 (EST) Message-Id: <200202261201.HAA23766@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 26 Feb 2002 12:00:33.0515 (UTC) FILETIME=[31B55BB0:01C1BEBD] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-05.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Feb 2002 07:01:34 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-05.txt Pages : 8 Date : 25-Feb-02 The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it 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-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-3way-05.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-05.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: <20020225142402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225142402.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Feb 26 10:04:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02375 for ; Tue, 26 Feb 2002 10:04:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1QEqRL92384; Tue, 26 Feb 2002 06:52:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1QEkUL92343 for ; Tue, 26 Feb 2002 06:46:30 -0800 (PST) (envelope-from rsaluja@nortelnetworks.com) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps0kn.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QEroP06227 for ; Tue, 26 Feb 2002 09:53:50 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QEp7V05567 for ; Tue, 26 Feb 2002 09:51:07 -0500 (EST) Received: from lead.engeast (lead [192.32.226.44]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id JAA18164; Tue, 26 Feb 2002 09:53:39 -0500 for Received: from nortelnetworks.com (localhost [127.0.0.1]) by lead.engeast (8.9.3+Sun/8.9.1) with ESMTP id JAA10534 for ; Tue, 26 Feb 2002 09:53:39 -0500 (EST) Message-ID: <3C7BA173.7C575718@nortelnetworks.com> From: "Rajesh Saluja" X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "isis-wg@spider.juniper.net" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] draft-ietf-isis-3way-05.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Feb 2002 09:53:39 -0500 Content-Transfer-Encoding: 7bit I have submitted draft-ietf-isis-3way-05.txt and I believe that the draft is once again ready for last call. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-05.txt The only technical difference from draft-ietf-isis-3way-04.txt is: In section 3.1, Neighbor Extended Local Circuit ID (four octets, if Neighbor System ID is present) is replaced with : Neighbor Extended Local Circuit ID if known (four octets) Thanks, Rajesh _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 27 15:34:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16361 for ; Wed, 27 Feb 2002 15:34:45 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1RKHQL18519; Wed, 27 Feb 2002 12:17:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com (f122.law7.hotmail.com [216.33.237.122]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1RK9eL18476 for ; Wed, 27 Feb 2002 12:09:40 -0800 (PST) (envelope-from sboddapa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Feb 2002 12:17:11 -0800 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 27 Feb 2002 20:17:10 GMT X-Originating-IP: [63.104.212.252] From: "Suresh Boddapati" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Feb 2002 20:17:11.0039 (UTC) FILETIME=[BCD470F0:01C1BFCB] Subject: [Isis-wg] IP Reachable Address MIB table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Feb 2002 20:17:10 I am a little confused about the IP Reachable Address MIB table. The table description says "The table of IP Reachable Addresses to networks, subnetworks or hosts either manually configured or learned from another protocol" The indices of this table are SysInstance, CircIndex, IPRAType and IPRAIndex. Can someone clarify the following: 1) What does manual configuration mean in this context? Is it referring to the internal reachability (the IP subnets of the circuits - represented by circIndex - on which ISIS is enabled)? 2) What does "learned from another protocol" mean in this context? Is it the redistributed routes from another protocol. If so, what is isisCircIndex doing as an index? Does it mean only those redistributed routes that can be reached over a ckt that has ISIS enabled on it? Maybe I am totally off. Any help is appreciated. Thanks. Regards, Suresh _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Feb 27 19:08:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25112 for ; Wed, 27 Feb 2002 19:08:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1RNtsL19482; Wed, 27 Feb 2002 15:55:54 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1RNQtL19349 for ; Wed, 27 Feb 2002 15:26:55 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1RNYhr20533; Wed, 27 Feb 2002 18:34:43 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-221.cisco.com [10.82.240.221]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAW03307; Wed, 27 Feb 2002 18:34:23 -0500 (EST) Message-Id: <4.3.2.7.2.20020227181859.01d5b9f0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Suresh Boddapati" From: Jeff Learman Subject: Re: [Isis-wg] IP Reachable Address MIB table Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Feb 2002 18:34:21 -0500 At 03:17 PM 2/27/2002, Suresh Boddapati wrote: >I am a little confused about the IP Reachable Address MIB table. The table description says >"The table of IP Reachable Addresses to networks, subnetworks or hosts either manually configured or learned from another protocol" > >The indices of this table are SysInstance, CircIndex, IPRAType and IPRAIndex. > >Can someone clarify the following: >1) What does manual configuration mean in this context? Is it referring to the internal reachability (the IP subnets of the circuits - represented by circIndex - on which ISIS is enabled)? No, these are destinations that are called "reachable address prefixes" in section 6.3 of 19589. They are typically addresses that are outside the routing domain (autonomous system in IP parlance), ones that are NOT subnet addresses of directly attached subnets. >2) What does "learned from another protocol" mean in this context? An example would be if you're running BGP and IS-IS level 2 on the same router (which would be a boundary intermediate system, BIS.) BGP learns about routes in the "outside world", IS-IS propagates this knowledge to other L2 routers so that all L2 routers can figure out the closest BIS serving that address. (Note: with clever use of metrics it may be possible to provide a shortest path to the destination, rather than a shortest path to a BIS serving the destination -- I don't know.) >Is it the redistributed routes from another protocol. If so, what is isisCircIndex doing as an index? This is the index of the circuit leading to the router in the other domain, serving the external addresses. >Does it mean only those redistributed routes that can be reached over a ckt that has ISIS enabled on it? No, the circuit does not have to be one that has IS-IS enabled. >Maybe I am totally off. Any help is appreciated. Thanks. > >Regards, > >Suresh > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 28 04:42:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15522 for ; Thu, 28 Feb 2002 04:42:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1S9RpL22013; Thu, 28 Feb 2002 01:27:51 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from hotmail.com ([216.33.237.45]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1S0PBL19638 for ; Wed, 27 Feb 2002 16:25:11 -0800 (PST) (envelope-from sboddapa@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Feb 2002 16:32:37 -0800 Received: from 63.104.212.252 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 28 Feb 2002 00:32:37 GMT X-Originating-IP: [63.104.212.252] From: "Suresh Boddapati" To: jlearman@cisco.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] IP Reachable Address MIB table Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Feb 2002 00:32:37.0449 (UTC) FILETIME=[6C150390:01C1BFEF] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Feb 2002 00:32:37 I guess my whole doubt is related to the isisCircIndex being an index of the table. Per the MIB, isisCircIndex is defined as "The identifier of this circuit, unique within the instance of the protocol. This object follows the index behavior. This is for SNMP purposes only and has no relation to any protocol value". isisCircIndex is one of the indices into the isisCircTable. Note this is not isisCircIfIndex which is a member of the isisCircTable (not an index) and is defined as "The value of ifIndex for the interface to which this circuit corresponds. This object cannot be modified after creation" Now if you say >This is the index of the circuit leading to the router in the other >domain, serving the external addresses. and if ISIS need not be enabled on that interface, then how can there be an index for that interface because a row corresponding to that interface does not exist in the isisCircTable. If we take an example, -------Router------- if1 if2 ISIS if1 has ISIS enabled which caused a row to be created in the Circ table with circindex say id1. if2 does not have ISIS enabled and therefore does not have any index corresponding to that circuit in the isisCircTable because the row does not exist. If if2 is the interface leading to the external destination, how can you represent the circIndex for that interface. One could argue this is implementation dependent; one could always create rows in the ISIS circ table for all the interfaces in the system and mark them as not in service, I suppose, but is this a good design of the MIB table? If all one wanted is to know all the external destinations that ISIS has learned from other protocol, why not index it without using the circIndex and list the outgoing interface as one of the members in the table and make it isisCircIfIndex instead of isisCircIndex? Am I missing something. Thanks. Regards, Suresh >From: Jeff Learman >To: "Suresh Boddapati" >CC: isis-wg@spider.juniper.net >Subject: Re: [Isis-wg] IP Reachable Address MIB table >Date: Wed, 27 Feb 2002 18:34:21 -0500 > >At 03:17 PM 2/27/2002, Suresh Boddapati wrote: > >I am a little confused about the IP Reachable Address MIB table. The >table description says > >"The table of IP Reachable Addresses to networks, subnetworks or hosts >either manually configured or learned from another protocol" > > > >The indices of this table are SysInstance, CircIndex, IPRAType and >IPRAIndex. > > > >Can someone clarify the following: > >1) What does manual configuration mean in this context? Is it referring >to the internal reachability (the IP subnets of the circuits - represented >by circIndex - on which ISIS is enabled)? > >No, these are destinations that are called "reachable address prefixes" in >section 6.3 of 19589. They are typically addresses that are outside the >routing domain (autonomous system in IP parlance), ones that are NOT >subnet addresses of directly attached subnets. > > >2) What does "learned from another protocol" mean in this context? > >An example would be if you're running BGP and IS-IS level 2 on the same >router (which would be a boundary intermediate system, BIS.) BGP learns >about routes in the "outside world", IS-IS propagates this knowledge to >other L2 routers so that all L2 routers can figure out the closest BIS >serving that address. (Note: with clever use of metrics it may be >possible to provide a shortest path to the destination, rather than a >shortest path to a BIS serving the destination -- I don't know.) > > >Is it the redistributed routes from another protocol. If so, what is >isisCircIndex doing as an index? > >This is the index of the circuit leading to the router in the other >domain, serving the external addresses. > > >Does it mean only those redistributed routes that can be reached over a >ckt that has ISIS enabled on it? > >No, the circuit does not have to be one that has IS-IS enabled. > > > >Maybe I am totally off. Any help is appreciated. Thanks. > > > >Regards, > > > >Suresh > > > >_________________________________________________________________ > >Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 28 06:24:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16971 for ; Thu, 28 Feb 2002 06:24:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1SBBpL22987; Thu, 28 Feb 2002 03:11:51 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1SAlVL22409 for ; Thu, 28 Feb 2002 02:47:31 -0800 (PST) (envelope-from mukula@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 28 Feb 2002 16:42:14 +0530 Received: from mukula (mukula.future.futsoft.com [10.8.3.41]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g1SAsWS15913; Thu, 28 Feb 2002 16:24:32 +0530 Reply-To: From: "mukula" To: Cc: Message-Id: <001b01c1c046$5a98eda0$2903080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: [Isis-wg] testing point-to-point functionalities of ISIS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Feb 2002 16:24:53 +0530 Content-Transfer-Encoding: 8bit Hi all, I am doing ISIS testing here. To test point-to-point functionality of ISIS I am getting use of serial link of cisco router with ppp encapsulation. At other side i am running pppd software freely available. so my doubt is whether pppd support ISIS or not. Because for this i think pppd has to negotiate OSINLCP (osi network layer control protocol) in NCP phase of PPP, which pppd does not support. Can any one help me out in this wheather i am correct or not. Is there any other ppp freeware is available ? Regards, -Mukul -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Suresh Boddapati Sent: Thursday, 28 February 2002 12:33 AM To: jlearman@cisco.com Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] IP Reachable Address MIB table I guess my whole doubt is related to the isisCircIndex being an index of the table. Per the MIB, isisCircIndex is defined as "The identifier of this circuit, unique within the instance of the protocol. This object follows the index behavior. This is for SNMP purposes only and has no relation to any protocol value". isisCircIndex is one of the indices into the isisCircTable. Note this is not isisCircIfIndex which is a member of the isisCircTable (not an index) and is defined as "The value of ifIndex for the interface to which this circuit corresponds. This object cannot be modified after creation" Now if you say >This is the index of the circuit leading to the router in the other >domain, serving the external addresses. and if ISIS need not be enabled on that interface, then how can there be an index for that interface because a row corresponding to that interface does not exist in the isisCircTable. If we take an example, -------Router------- if1 if2 ISIS if1 has ISIS enabled which caused a row to be created in the Circ table with circindex say id1. if2 does not have ISIS enabled and therefore does not have any index corresponding to that circuit in the isisCircTable because the row does not exist. If if2 is the interface leading to the external destination, how can you represent the circIndex for that interface. One could argue this is implementation dependent; one could always create rows in the ISIS circ table for all the interfaces in the system and mark them as not in service, I suppose, but is this a good design of the MIB table? If all one wanted is to know all the external destinations that ISIS has learned from other protocol, why not index it without using the circIndex and list the outgoing interface as one of the members in the table and make it isisCircIfIndex instead of isisCircIndex? Am I missing something. Thanks. Regards, Suresh >From: Jeff Learman >To: "Suresh Boddapati" >CC: isis-wg@spider.juniper.net >Subject: Re: [Isis-wg] IP Reachable Address MIB table >Date: Wed, 27 Feb 2002 18:34:21 -0500 > >At 03:17 PM 2/27/2002, Suresh Boddapati wrote: > >I am a little confused about the IP Reachable Address MIB table. The >table description says > >"The table of IP Reachable Addresses to networks, subnetworks or hosts >either manually configured or learned from another protocol" > > > >The indices of this table are SysInstance, CircIndex, IPRAType and >IPRAIndex. > > > >Can someone clarify the following: > >1) What does manual configuration mean in this context? Is it referring >to the internal reachability (the IP subnets of the circuits - represented >by circIndex - on which ISIS is enabled)? > >No, these are destinations that are called "reachable address prefixes" in >section 6.3 of 19589. They are typically addresses that are outside the >routing domain (autonomous system in IP parlance), ones that are NOT >subnet addresses of directly attached subnets. > > >2) What does "learned from another protocol" mean in this context? > >An example would be if you're running BGP and IS-IS level 2 on the same >router (which would be a boundary intermediate system, BIS.) BGP learns >about routes in the "outside world", IS-IS propagates this knowledge to >other L2 routers so that all L2 routers can figure out the closest BIS >serving that address. (Note: with clever use of metrics it may be >possible to provide a shortest path to the destination, rather than a >shortest path to a BIS serving the destination -- I don't know.) > > >Is it the redistributed routes from another protocol. If so, what is >isisCircIndex doing as an index? > >This is the index of the circuit leading to the router in the other >domain, serving the external addresses. > > >Does it mean only those redistributed routes that can be reached over a >ckt that has ISIS enabled on it? > >No, the circuit does not have to be one that has IS-IS enabled. > > > >Maybe I am totally off. Any help is appreciated. Thanks. > > > >Regards, > > > >Suresh > > > >_________________________________________________________________ > >Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Feb 28 16:06:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19651 for ; Thu, 28 Feb 2002 16:06:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1SKqXL25681; Thu, 28 Feb 2002 12:52:33 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1SKXfL25591 for ; Thu, 28 Feb 2002 12:33:41 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Suresh Boddapati'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IP Reachable Address MIB table MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Feb 2002 15:41:10 -0500 > If if2 is the interface leading to the external destination, > how can you represent the circIndex for that interface. Right. This does have my shorts in a knot. I would like to take a step back and look at the IP Reachable Address table. From the perspective of ISIS, the notion of where the route comes out is not relevant (see sig). I will remove isisCircIndex from the table. - jeff parker "'Who cares where they come down? That's not my department', says Werner von Braun." isisIPRAEntry OBJECT-TYPE SYNTAX IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines an IP Reachable Address to a network, subnetwork or host." INDEX { isisSysInstance, isisCircIndex, isisIPRAType, isisIPRAIndex } ::= { isisIPRATable 1 } _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg