Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29699; 16 Jan 96 11:26 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa29695; 16 Jan 96 11:26 EST Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa12760; 16 Jan 96 11:26 EST Received: (from daemon@localhost) by atlas.xylogics.com (8.7.3/8.7.3) id LAA00517 for ietf-rip-include; Tue, 16 Jan 1996 11:21:33 -0500 (EST) Received: from huey.xylogics.com (huey.xylogics.com [132.245.33.139]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id LAA00514 for ; Tue, 16 Jan 1996 11:21:32 -0500 (EST) Received: by huey.xylogics.com id AA16701 (4.1/UK-doug-951219); Tue, 16 Jan 96 10:34:13 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gary Scott Malkin Date: Tue, 16 Jan 96 10:34:13 EST Message-Id: <16701.9601161534@huey.xylogics.com> To: ietf-rip@xylogics.com Subject: RIPng updates I'm still waiting for updates to the RIPng spec for the addressing issues which have been raised. There is little time until the next IETF, so if you volunteered to write something, please do it soon. Many Thanks. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 238-6237 Pick two!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02190; 22 Jan 96 9:13 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id bs01844; 22 Jan 96 9:13 EST Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa05986; 22 Jan 96 7:56 EST Received: (from daemon@localhost) by atlas.xylogics.com (8.7.3/8.7.3) id HAA00974 for ietf-rip-include; Mon, 22 Jan 1996 07:50:54 -0500 (EST) Received: from lynx.spider.co.uk (lynx.spider.co.uk [134.191.64.5]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id HAA00971 for ; Mon, 22 Jan 1996 07:50:32 -0500 (EST) Received: from orbweb.spider.co.uk (orbweb.spider.co.uk [89.0.0.10]) by lynx.spider.co.uk (8.6.12/8.6.12) with ESMTP id MAA09428 for ; Mon, 22 Jan 1996 12:48:44 GMT Received: (from gerry@localhost) by orbweb.spider.co.uk (8.6.12/8.6.9) id MAA25254; Mon, 22 Jan 1996 12:42:49 GMT Date: Mon, 22 Jan 1996 12:42:49 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gerry Meyer Message-Id: <199601221242.MAA25254@orbweb.spider.co.uk> To: ietf-rip@xylogics.com, waters@marvin.enet.dec.com Subject: Re: Triggered RIP Qs Cc: gerry@orbweb.spider.co.uk Steve, > Gerry, > > Returning to a point I raised a few months ago : The > possibility of creating a Triggered-RIP compatible solution > that used aspects of 'Piggybacking' to remove the problem > of high connection charges (ISDN links) on large/complex > networks. > > > Problem : > > If the network has a large number of subnets and > IPX routes/services, the current Triggered RIP proposal could > have a very high (and possibly unnecessary) cost. As an example, > based on the charging scheme in the U.K : > > Connection charge - 5pence for first 30seconds then > charged per second. If you make rapid calls/clears, > the cost soon becomes awesome : > > Idle time 5 seconds > > For the case of the route/service updates at > once every 5 seconds, the call would never be > disconnected and would cost > > 10p*60*24*7*4 for a four week period(approx 4,000pounds) > > With this value of idle timer, the worst case is > an update every 6 seconds : > > This allows for 5 calls in a 30second period so the > cost would be worst by a factor of 5 - 20,000 pounds > per month per B-channel. Hmmm. Rather a stable network you have there in your example. > > I think it is a problem if the Triggered RIP algorithm does not take > account of the call state. Triggered RIP is of general use on all > 'bandwidth challenged' WAN links (unlike Piggyback approaches) due > to the elimination of broadcast and the side-effect of reducing > line-hogging (one Response in-flight needed an Ack), but is capable of > incurring very high connection charges with call-state sensitivity. > > A possible addition (which would be compatible with the current RFC) > would be to add an extra state to the state-table that allowed for > call-state sensitivity. The new route/service information is marked > as 'NEW', as currently suggested, but the Responses are not sent until > a connection is established to send data. > > This approach would still need the Initialisation stage of route > flushing/learning and it would make sense to allow for a timer to > control how long after restart the router changed to Piggyback state. > Another possible timer could control a 'forced-update' to empty new > information if no data-triggered opportunity occurred in that time. My view is that Triggered RIP (and Demand RIP before it) is a drop-in- replacement for regular broadcast RIP in ANY network topology. There is no degradation in stability or routing knowledge. Once you start playing around with delaying updates all bets are off. Now that is not to say that some implementation might not provide as an 'enhancement' something along the lines of what you are suggesting with a large GOVERNMENT HEALTH (Surgeon General's) WARNING that it may damage the health of you network. But it should NOT be part of any standard. I think your 'network' above is probaly better handled by the router understanding a policy - and only letting selected routes filter through. > Steve. > >To Distribution List: > >gerry, >"ietf-rip@xylogics.com"@vbormc@MRGATE > >CC Distribution List: > >NAME: chris gunner , >NAME: carol iturralde , >NAME: Albra bonardi , >NAME: Jitu Patel , >NAME: Dave Forster , >NAME: Mike Shand , >NAME: Tony Hart , >NAME: Mark Gillott Thats some mailer you have. It almost makes the Lotus Notes one I've been left in an inheritance look good ;-) Gerry   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18428; 22 Jan 96 19:24 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18424; 22 Jan 96 19:24 EST Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa19755; 22 Jan 96 19:24 EST Received: (from daemon@localhost) by atlas.xylogics.com (8.7.3/8.7.3) id TAA13015 for ietf-rip-include; Mon, 22 Jan 1996 19:23:11 -0500 (EST) Received: from marvin.micom.com (marvin.micom.com [199.30.19.44]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id TAA13012 for ; Mon, 22 Jan 1996 19:23:10 -0500 (EST) Received: by marvin.micom.com (4.1/SMI-4.1) id AA10775; Mon, 22 Jan 96 16:22:32 PST Date: Mon, 22 Jan 96 16:22:32 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rajesh Sugunadass Message-Id: <9601230022.AA10775@marvin.micom.com> To: ietf-rip@xylogics.com Subject: RIP / OSPF interaction Hi all, While announcing routes learned through OSPF to routers running RIP, how to map OSPF metric from OSPF to RIP metric (has to be lessthan 16)? Any info or pointers about this would really be appreciated. You can reach me directly at 'rajesh@micom.com`. Thank you for your time and effort, Rajesh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20486; 22 Jan 96 22:21 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20482; 22 Jan 96 22:21 EST Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa22390; 22 Jan 96 22:21 EST Received: (from daemon@localhost) by atlas.xylogics.com (8.7.3/8.7.3) id WAA14909 for ietf-rip-include; Mon, 22 Jan 1996 22:19:48 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id WAA14906 for ; Mon, 22 Jan 1996 22:19:47 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id TAA15063; Mon, 22 Jan 1996 19:19:09 -0800 Message-Id: <199601230319.TAA15063@puli.cisco.com> To: Rajesh Sugunadass Cc: ietf-rip@xylogics.com Subject: Re: RIP / OSPF interaction In-Reply-To: Your message of "Mon, 22 Jan 1996 16:22:32 PST." <9601230022.AA10775@marvin.micom.com> Date: Mon, 22 Jan 1996 19:19:09 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Paul Traina Apples and oranges. I would not suggest metric mapping. From: rajesh@micom.com (Rajesh Sugunadass) Subject: RIP / OSPF interaction Hi all, While announcing routes learned through OSPF to routers running RIP, how to map OSPF metric from OSPF to RIP metric (has to be lessthan 16)? Any info or pointers about this would really be appreciated. You can reach me directly at 'rajesh@micom.com`. Thank you for your time and effort, Rajesh   Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21620; 26 Jan 96 15:22 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14446; 26 Jan 96 15:22 EST Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21579; 26 Jan 96 15:22 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21390; 26 Jan 96 15:15 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14207; 26 Jan 96 15:15 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21378; 26 Jan 96 15:15 EST To: IETF-Announce: ; cc: ietf-rip@xylogics.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: The IESG Subject: Last Call: RIPv1 Applicability Statement for Historic Status to Informational Reply-to: iesg@IETF.CNRI.Reston.VA.US Date: Fri, 26 Jan 96 15:15:23 -0500 X-Orig-Sender: scoya@CNRI.Reston.VA.US Message-ID: <9601261515.aa21378@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Routing Information Protocol Working Group to consider "RIPv1 Applicability Statement for Historic Status" for the status of Informational. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by February 9, 1996.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09908; 19 Jan 96 8:20 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09904; 19 Jan 96 8:20 EST Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa05664; 19 Jan 96 8:20 EST Received: (from daemon@localhost) by atlas.xylogics.com (8.7.3/8.7.3) id IAA19273 for ietf-rip-include; Fri, 19 Jan 1996 08:16:05 -0500 (EST) Received: from ns1.digital.fr (ns1.digital.fr [193.56.15.3]) by atlas.xylogics.com (8.7.3/8.7.3) with ESMTP id IAA19270 for ; Fri, 19 Jan 1996 08:15:49 -0500 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id OAA15398 for ; Fri, 19 Jan 1996 14:18:58 +0100 Received: from rdgeng.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id OAA06617 for ; Fri, 19 Jan 1996 14:10:04 +0100 Message-Id: <199601191310.OAA06617@vbormc.vbo.dec.com> Received: from rdgeng.enet; by vbormc.enet; Fri, 19 Jan 96 14:10:05 MET Date: Fri, 19 Jan 96 14:10:05 MET To: mail11: ; Apparently-To: ietf-rip@xylogics.com Subject: Re: Triggered RIP Qs (waters@marvin.enet.dec.com) From: NAME: Stephen Waters (MARVIN::WATERS) ADDR: @REO marvin::waters To: See Below CC: See Below Gerry, Returning to a point I raised a few months ago : The possibility of creating a Triggered-RIP compatible solution that used aspects of 'Piggybacking' to remove the problem of high connection charges (ISDN links) on large/complex networks. Problem : If the network has a large number of subnets and IPX routes/services, the current Triggered RIP proposal could have a very high (and possibly unnecessary) cost. As an example, based on the charging scheme in the U.K : Connection charge - 5pence for first 30seconds then charged per second. If you make rapid calls/clears, the cost soon becomes awesome : Idle time 5 seconds For the case of the route/service updates at once every 5 seconds, the call would never be disconnected and would cost 10p*60*24*7*4 for a four week period(approx 4,000pounds) With this value of idle timer, the worst case is an update every 6 seconds : This allows for 5 calls in a 30second period so the cost would be worst by a factor of 5 - 20,000 pounds per month per B-channel. I think it is a problem if the Triggered RIP algorithm does not take account of the call state. Triggered RIP is of general use on all 'bandwidth challenged' WAN links (unlike Piggyback approaches) due to the elimination of broadcast and the side-effect of reducing line-hogging (one Response in-flight needed an Ack), but is capable of incurring very high connection charges with call-state sensitivity. A possible addition (which would be compatible with the current RFC) would be to add an extra state to the state-table that allowed for call-state sensitivity. The new route/service information is marked as 'NEW', as currently suggested, but the Responses are not sent until a connection is established to send data. This approach would still need the Initialisation stage of route flushing/learning and it would make sense to allow for a timer to control how long after restart the router changed to Piggyback state. Another possible timer could control a 'forced-update' to empty new information if no data-triggered opportunity occurred in that time. Steve. To Distribution List: gerry, "ietf-rip@xylogics.com"@vbormc@MRGATE CC Distribution List: NAME: chris gunner , NAME: carol iturralde , NAME: Albra bonardi , NAME: Jitu Patel , NAME: Dave Forster , NAME: Mike Shand , NAME: Tony Hart , NAME: Mark Gillott