Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06648; 17 Oct 94 16:06 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa06644; 17 Oct 94 16:06 EDT Received: from gw1.att.com ([192.20.239.133]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id PAA12867 for ; Mon, 17 Oct 1994 15:38:44 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: shur@arch4.ho.att.com Received: from arch4.ho.att.com by ig1.att.att.com id AA27163; Mon, 17 Oct 94 14:42:35 EDT Received: from dahlia.ho.att.com by arch4.ho.att.com (4.1/EMS-1.1 main.cf 1/8/94 (SMI-4.1/SVR4)) id AA21139; Mon, 17 Oct 94 14:43:48 EDT Received: by dahlia.ho.att.com (4.1/EMS-1.1 SunOS) id AA09254; Mon, 17 Oct 94 14:43:19 EDT Date: Mon, 17 Oct 94 14:43:19 EDT Message-Id: <9410171843.AA09254@dahlia.ho.att.com> To: rolc@maelstrom.timeplex.com Subject: Questions on NHRP-02 draft I have some questions about the NHRP-02 (August 25) draft. The document describes the details including packet formats by which a request for binding info between a destination IP address and an NBMA next-hop address is propagated through the NBMA network and replies are generated. What I am not clear about is the details of the packet forwarding procedure followed by a station that is not a server directly connected to the NBMA network. Section 2 states that when a station S wants to resolve the NBMA address corresponding to the IP address of an intended destination D, it forms a NHRP request and forwards the request to its NHS (whose identity is determined by configuration). It then describes how the NHRP request is resolved by forwarding the NHRP request among NHS's as necessary, and that this info. is cached by NHSs. What is done with the IP-NBMA address binding sent back to the originating station S? I assume that client stations like S also maintain a cache of received NHRP reply bindings. Presumably, station S will update its cache with the results of NHRP replies. Furthermore, presumably S will consult its cache prior to the issuing of a NHRP request (and not issue a request if there is a hit). Also when exactly do stations like S register with their NHSs? When they boot up? Since there is a holding time associated with the binding, do stations have to periodically re-register? Or do NHS's request stations to re-register when the holding time expires? I would appreciate it if someone could either direct me to the appropriate text in the document, or clarify on the list. Thanks, David Shur (d.shur@att.com).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00468; 18 Oct 94 4:08 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa00463; 18 Oct 94 4:08 EDT Received: from lager.cisco.com ([131.108.11.55]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id EAA02753 for ; Tue, 18 Oct 1994 04:00:21 -0400 Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA24728; Tue, 18 Oct 1994 00:58:48 -0700 Date: Tue, 18 Oct 1994 00:58:48 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tony Li Message-Id: <199410180758.AAA24728@lager.cisco.com> To: shur@arch4.ho.att.com Cc: rolc@maelstrom.timeplex.com Subject: Questions on NHRP-02 draft I have some questions about the NHRP-02 (August 25) draft. The document describes the details including packet formats by which a request for binding info between a destination IP address and an NBMA next-hop address is propagated through the NBMA network and replies are generated. What I am not clear about is the details of the packet forwarding procedure followed by a station that is not a server directly connected to the NBMA network. Section 2 states that when a station S wants to resolve the NBMA address corresponding to the IP address of an intended destination D, it forms a NHRP request and forwards the request to its NHS (whose identity is determined by configuration). It then describes how the NHRP request is resolved by forwarding the NHRP request among NHS's as necessary, and that this info. is cached by NHSs. What is done with the IP-NBMA address binding sent back to the originating station S? I assume that client stations like S also maintain a cache of received NHRP reply bindings. Presumably, station S will update its cache with the results of NHRP replies. Furthermore, presumably S will consult its cache prior to the issuing of a NHRP request (and not issue a request if there is a hit). Exactly. Also when exactly do stations like S register with their NHSs? Either at boot time or statically. Since there is a holding time associated with the binding, do stations have to periodically re-register? Or do NHS's request stations to re-register when the holding time expires? My understanding is that they should periodically re-register. As we can expect relatively long hold times which are known to the station, this is very much a background low bandwidth task. Tony   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04077; 18 Oct 94 11:41 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa04073; 18 Oct 94 11:41 EDT Received: from roseau.lirmm.fr ([193.49.104.9]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id LAA13317 for ; Tue, 18 Oct 1994 11:38:12 -0400 Received: (chirouze@localhost) by roseau.lirmm.fr (8.6.9/8.6.4) id PAA19474 for rolc@maelstrom.timeplex.com; Tue, 18 Oct 1994 15:25:43 +0100 Date: Tue, 18 Oct 1994 15:25:43 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Michel CHIROUZE Message-Id: <199410181425.PAA19474@roseau.lirmm.fr> To: rolc@maelstrom.timeplex.com SUBSCRIBE chirouze chirouze@lirmm.fr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14170; 18 Oct 94 22:57 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa14166; 18 Oct 94 22:57 EDT Received: from sol.sura.net ([128.167.1.100]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id WAA02159 for ; Tue, 18 Oct 1994 22:41:19 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rcoltun@sura.net Received: by sol.sura.net for rolc@maelstrom.Timeplex.COM (5.65b/(SURAnet $Revision: 1.29 $)) id AA10086; Tue, 18 Oct 94 22:36:34 -0400 Date: Tue, 18 Oct 94 22:36:34 -0400 Message-Id: <9410190236.AA10086@sol.sura.net> To: rolc@maelstrom.timeplex.com Subject: NHRP issue NHRP looks quite reasonable to me except for the fact that routers will have to periodically send out requests: >8.1 Router-to-Router Operation > > In practice, the initiating and responding stations may be either > hosts or routers. However, there is a possibility under certain > conditions that a stable routing loop may occur if NHRP is used > between two routers. This situation can be avoided if there are no > "back door" paths between the entry and egress router outside of the > NBMA network, and can be ameliorated by periodically reissuing the > NHRP request. If these conditions cannot be satisfied, the use of > NHRP between routers is not recommended. In my mind this a bit of a hand-wave although I certainly don't have better solution; doesn't look like it will scale all that well. Does it give anyone else heartburn? One additional (implementatin related) question - suppose a NHS has more than one ATM port. How is it supposed to determine if both ports are on the same NBMA network? It certainly can look at either IP or P-NNI and make some determinations... Thanks, ---rob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18758; 19 Oct 94 0:35 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa18754; 19 Oct 94 0:35 EDT Received: from feta.cisco.com ([192.31.7.22]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id AAA04119 for ; Wed, 19 Oct 1994 00:28:37 -0400 Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA27753; Tue, 18 Oct 1994 21:27:06 -0700 Date: Tue, 18 Oct 1994 21:27:06 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Katz Message-Id: <199410190427.VAA27753@feta.cisco.com> To: rcoltun@sura.net Cc: rolc@maelstrom.timeplex.com In-Reply-To: rcoltun@sura.net's message of Tue, 18 Oct 94 22:36:34 -0400 <9410190236.AA10086@sol.sura.net> Subject: NHRP issue From: rcoltun@sura.net Date: Tue, 18 Oct 94 22:36:34 -0400 NHRP looks quite reasonable to me except for the fact that routers will have to periodically send out requests: >8.1 Router-to-Router Operation > > In practice, the initiating and responding stations may be either > hosts or routers. However, there is a possibility under certain > conditions that a stable routing loop may occur if NHRP is used > between two routers. This situation can be avoided if there are no > "back door" paths between the entry and egress router outside of the > NBMA network, and can be ameliorated by periodically reissuing the > NHRP request. If these conditions cannot be satisfied, the use of > NHRP between routers is not recommended. In my mind this a bit of a hand-wave although I certainly don't have better solution; doesn't look like it will scale all that well. Does it give anyone else heartburn? I think that ultimately the router-to-router case will involve running a stripped-down BGP or IDRP across the short-cut path. This will make it possible to detect the looping case. It's intentionally handwaved for the moment, however. One additional (implementatin related) question - suppose a NHS has more than one ATM port. How is it supposed to determine if both ports are on the same NBMA network? It certainly can look at either IP or P-NNI and make some determinations... The fundamental issue is in how the NBMA network IDs (a.k.a. "fabric numbers") are assigned and whether they show up in other protocols. Ultimately the boundaries of a fabric have to be configured somewhere, and if a single fabric is being administratively treated as multiple fabrics, then the configuration point would seem to be at the IP layer. Keep in mind that this is likely to be used for more than just ATM. X.25 still sells like crazy...   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01979; 19 Oct 94 9:07 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa01974; 19 Oct 94 9:07 EDT Received: from watson.ibm.com ([129.34.139.4]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id IAA15383 for ; Wed, 19 Oct 1994 08:47:44 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199410191247.IAA15383@maelstrom.acton.timeplex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3139; Wed, 19 Oct 94 08:23:29 EDT Date: Wed, 19 Oct 94 08:23:09 EDT To: dkatz@cisco.com, rcoltun@sura.net cc: rolc@maelstrom.timeplex.com Subject: NHRP issue Ref: Your note of Tue, 18 Oct 1994 21:27:06 -0700 Dave, >I think that ultimately the router-to-router case will involve >running a stripped-down BGP or IDRP across the short-cut path. >This will make it possible to detect the looping case. That seems quite reasonable -- you use NHRP to find the exit router, but once the router is found you establish *routing protocol* peering with this router to acquire (and possibly propagate) routing information. The stripped down BGP or IDRP should allow you to acquire (and maintain) routing information only about a subset of routes (the one you are interested in) available at the peer (the exit router). Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02005; 19 Oct 94 9:10 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa02000; 19 Oct 94 9:10 EDT Received: from nbkanata.Newbridge.COM ([192.75.23.5]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id JAA15857 for ; Wed, 19 Oct 1994 09:08:02 -0400 Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA21867; Wed, 19 Oct 94 09:00:35 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA23066; Wed, 19 Oct 94 09:00:35 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA18435; Wed, 19 Oct 94 09:06:25 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA03614; Wed, 19 Oct 1994 09:06:24 +0500 Date: Wed, 19 Oct 1994 09:06:24 +0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9410191306.AA03614@lobster.Newbridge.COM> To: rolc@maelstrom.timeplex.com Subject: Re: NHRP issue X-Sun-Charset: US-ASCII Content-Length: 540 Rob Coltun asks whether the router-router behavior will scale. As described, the answer is no. This is unfortunate. Indeed, before we can move this from proposed to draft standard we will need a better handle on this problem. (There are several possible solutions on the remote horizon.) However, I don't think that this should stop us from doing the best job possible with NHRP. We need the tool for a lot of cases. Lets get a good document to "proposed". Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06105; 19 Oct 94 14:57 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa06100; 19 Oct 94 14:57 EDT Received: from lohi.dat.tele.fi ([131.177.104.142]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id OAA26336 for ; Wed, 19 Oct 1994 14:54:15 -0400 Message-Id: <199410191854.OAA26336@maelstrom.acton.timeplex.com> Received: from lohi.dat.tele.fi by lohi.dat.tele.fi id <12237-0@lohi.dat.tele.fi>; Wed, 19 Oct 1994 20:52:55 +0200 To: yakov@watson.ibm.com CC: dkatz@cisco.com, rcoltun@sura.net, rolc@maelstrom.timeplex.com In-reply-to: <199410191247.IAA15383@maelstrom.acton.timeplex.com> (yakov@watson.ibm.com) Subject: Re: NHRP issue Date: Wed, 19 Oct 1994 20:52:55 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@lohi.dat.tele.fi The stripped down BGP or IDRP should allow you to acquire (and maintain) routing information only about a subset of routes (the one you are interested in) available at the peer (the exit router). Yakov, are you also proposing that hosts would run this stripped down protocol? what bothers me here is that i would not like to complicate the hosts that much. what i would like to get for the hosts is nbma arp which is very easy to implement, scales as well as routing protocols in general do, and would give us a fast start in true end-to-end atm connectivity for video conferencing, etc. i'm afraid that, because of its complexity and problems, many nic vendors will not implement nhrp any time soon, which leaves the users in the dark and slows down wide scale atm deployment. or may be that is exactly the router vendors hope ... -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06240; 19 Oct 94 15:17 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa06236; 19 Oct 94 15:17 EDT Received: from curtis.ansremote.com ([152.161.2.3]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id PAA26943 for ; Wed, 19 Oct 1994 15:15:22 -0400 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id OAA00942; Wed, 19 Oct 1994 14:54:48 -0400 Message-Id: <199410191854.OAA00942@curtis.ansremote.com> To: rcoltun@sura.net cc: rolc@maelstrom.timeplex.com Reply-To: curtis@ans.net Subject: Re: NHRP issue In-reply-to: Your message of "Tue, 18 Oct 1994 22:36:34 EDT." <9410190236.AA10086@sol.sura.net> Date: Wed, 19 Oct 1994 14:54:42 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message <9410190236.AA10086@sol.sura.net>, rcoltun@sura.net writes: > > > NHRP looks quite reasonable to me except for the fact that routers > will have to periodically send out requests: > > >8.1 Router-to-Router Operation > > > > In practice, the initiating and responding stations may be either > > hosts or routers. However, there is a possibility under certain > > conditions that a stable routing loop may occur if NHRP is used > > between two routers. This situation can be avoided if there are no > > "back door" paths between the entry and egress router outside of the > > NBMA network, and can be ameliorated by periodically reissuing the > > NHRP request. If these conditions cannot be satisfied, the use of > > NHRP between routers is not recommended. > > In my mind this a bit of a hand-wave although I certainly don't have > better solution; doesn't look like it will scale all > that well. Does it give anyone else heartburn? Yes. But "If these conditions cannot be satisfied, the use of NHRP between routers is not recommended" covers it for us. :-) The scaling of redirects worries me more. A flapping class A will be fun. Right now you send one routing update. If 1,000 routes fail you send a few updates containing 1,000 routes (depending on how much fits in the PDUs). You could close the VCs from every host, and blackhole on transient. This doesn't work if hosts open one VC for all traffic to your router. Otherwise you just give the switches fits (a very sudden drop of lots of VCs and a big call setup load). You could leave the VCs open, forward, and send redirects. One redirect per VC, per some time period should keep you from sending one redirect per incoming packet. That means keeping track of when redirects were sent to each VC. This is OK except that if 1,000 routes change, you need to keep track of which VCs have been sent which redirects recently. The worst case state size is #routes * #VCs. Doesn't seem to me to scale well. The alternate is to keep no state and send one redirect per incoming packet. > Thanks, > ---rob Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06256; 19 Oct 94 15:17 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa06250; 19 Oct 94 15:17 EDT Received: from curtis.ansremote.com ([152.161.2.3]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id PAA26945 for ; Wed, 19 Oct 1994 15:15:28 -0400 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id OAA00953; Wed, 19 Oct 1994 14:57:22 -0400 Message-Id: <199410191857.OAA00953@curtis.ansremote.com> To: Dave Katz cc: rcoltun@sura.net, rolc@maelstrom.timeplex.com Reply-To: curtis@ans.net Subject: Re: NHRP issue In-reply-to: Your message of "Tue, 18 Oct 1994 21:27:06 PDT." <199410190427.VAA27753@feta.cisco.com> Date: Wed, 19 Oct 1994 14:57:11 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message <199410190427.VAA27753@feta.cisco.com>, Dave Katz writes: > > I think that ultimately the router-to-router case will involve running > a stripped-down BGP or IDRP across the short-cut path. This will make > it possible to detect the looping case. It's intentionally handwaved > for the moment, however. As I said before "If these conditions cannot be satisfied, the use of NHRP between routers is not recommended" covers it for us. :-) Maybe NHRP will work well enough for relatively small X.25 networks that don't connect big routers to them. A big X.25 NBMA and one router with connectivity to the rest of the Internet might work OK as well. Two or three such router, maybe not. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07041; 19 Oct 94 16:50 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa07036; 19 Oct 94 16:50 EDT Received: from watson.ibm.com ([129.34.139.4]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id QAA29673 for ; Wed, 19 Oct 1994 16:33:25 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199410192033.QAA29673@maelstrom.acton.timeplex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2269; Wed, 19 Oct 94 16:32:25 EDT Date: Wed, 19 Oct 94 16:31:15 EDT To: Juha.Heinanen@lohi.dat.tele.fi cc: rolc@maelstrom.timeplex.com Subject: NHRP issue Ref: Your note of Wed, 19 Oct 1994 20:52:55 +0200 Juha, >are you proposing that hosts would run this stripped down protocol ? No. I was proposing that *routers* will run this protocol as a mechanism to avoid routing loops. Yakov   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07055; 19 Oct 94 16:53 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa07051; 19 Oct 94 16:52 EDT Received: from watson.ibm.com ([129.34.139.4]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id QAA00289 for ; Wed, 19 Oct 1994 16:50:06 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: yakov@watson.ibm.com Message-Id: <199410192050.QAA00289@maelstrom.acton.timeplex.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2655; Wed, 19 Oct 94 16:48:09 EDT Date: Wed, 19 Oct 94 16:44:57 EDT To: curtis@ans.net cc: rolc@maelstrom.timeplex.com Subject: NHRP issue Ref: Your note of Wed, 19 Oct 1994 15:56:31 -0400 Curtis, >I haven't proposed the extensions needed to extend BGP to exchange >the export filter information, though this too can be covered >with optional BGP attribute. Same goes for IDRP. > >I'll leave it up to Yakov to design the PDUs if he has the time >and agrees with this approach. Work is already in progress on this. BGP spec that describes how to do this will be available no late than the end of next week. The spec would be applicable to IDRP as well (after minor editorial changes). Yakov.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09362; 19 Oct 94 21:06 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa09358; 19 Oct 94 21:06 EDT Received: from curtis.ansremote.com ([152.161.2.3]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id QAA28469 for ; Wed, 19 Oct 1994 16:01:12 -0400 Received: from curtis.ansremote.com (localhost [127.0.0.1]) by curtis.ansremote.com (8.6.5/8.6.5) with ESMTP id PAA01053; Wed, 19 Oct 1994 15:57:31 -0400 Message-Id: <199410191957.PAA01053@curtis.ansremote.com> To: Juha Heinanen cc: yakov@watson.ibm.com, dkatz@cisco.com, rcoltun@sura.net, rolc@maelstrom.timeplex.com Reply-To: curtis@ans.net Subject: Re: NHRP issue In-reply-to: Your message of "Wed, 19 Oct 1994 20:52:55 +0200." <199410191854.OAA26336@maelstrom.acton.timeplex.com> Date: Wed, 19 Oct 1994 15:56:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar In message <199410191854.OAA26336@maelstrom.acton.timeplex.com>, Juha Heinanen writes: > > The stripped down BGP or IDRP should allow you to acquire (and > maintain) routing information only about a subset of routes > (the one you are interested in) available at the peer (the exit router). > > Yakov, > > are you also proposing that hosts would run this stripped down protocol? > what bothers me here is that i would not like to complicate the hosts > that much. I'm not sure what you regard as the problem with running a routing protocol if it is specifically modified to accomodate hosts which have a need for limited information and which would prefer to keep their link completely idle at times. The problem is that we have not defined how to do this in sufficient detail. (See below). > what i would like to get for the hosts is nbma arp which is very easy to > implement, scales as well as routing protocols in general do, and would > give us a fast start in true end-to-end atm connectivity for video > conferencing, etc. I see NBMA ARP as a simpler alternative to NHRP to address the problem of finding the border router address. It is simpler because it doesn't have all the NHRP gunk that won't work anyway. :-) > i'm afraid that, because of its complexity and problems, many nic > vendors will not implement nhrp any time soon, which leaves the users in > the dark and slows down wide scale atm deployment. or may be that is > exactly the router vendors hope ... > > -- juha I don't see NHRP as relevant to ATM deployment (or anything for that matter). Other may use it. Maybe not. wrt - being more specific on what to do. For a host or small router, the NBMA provider router can be passive (not initiate connections). The host can take the routing session down when the link is not in use. Keepalives can be disabled. I think Cisco already allows this. For the NBMA, BGP or IDRP can be extended to allow a host to provide filter information, similar to export policy in gated, except peer provided. If the host needs an address it uses the default route temporarily. The routing daemon on the host requests a route to cover the destination. The provider returns the aggregate covering the destination and less specific aggregates indicating portions of the aggregate covered by more specific routes that are not being provided. The host would then receive updates reflecting changes to that aggregate that it now has. As destinations come into use that fall to the default route or to one of the more specific aggregates noted as "missing", the host can request more aggregates. As aggregates become unused (a host can periodically check the use counts in its routing table) a request can be sent to no longer receive updates for them. When all aggregates have been idle, the host will receive no routing traffic and with no keepalives, no traffic at all. It can then bring down the level 2 adjacency if that will reduce cost. The routing protocol part of this could easily be prototyped with PPP even though cut through is not possible. I've already proposed how to determine whether to send an NBMA ARP for the destination or the next hop after getting the BGP update. I haven't proposed the extensions needed to extend BGP to exchange the export filter information, though this too can be covered with optional BGP attributes. Same goes for IDRP. I'll leave it up to Yakov to design the PDUs if he has the time and agrees with this approach. Regards, Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13323; 25 Oct 94 22:31 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa13319; 25 Oct 94 22:31 EDT Received: from pv0f15.vincent.iastate.edu (pv0f15.vincent.iastate.edu [129.186.15.21]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id WAA12601 for ; Tue, 25 Oct 1994 22:18:52 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dixit@iastate.edu Received: by pv0f15.vincent.iastate.edu with sendmail-5.65 id ; Tue, 25 Oct 1994 21:16:51 -0500 Date: Tue, 25 Oct 1994 21:16:51 -0500 Message-Id: <9410260216.AA00786@pv0f15.vincent.iastate.edu> To: rolc@maelstrom.timeplex.com Hi !! I am graduate student in computer scince at Iowa state university. I am taking a course on Advanced computer networking this semester and as a part of that I need to write a paper on TCP/IP over atm. I just came to know that you all have been working on this. It would be extremely kind of you if you could send me some pointers where I could do some readup on this. Thanks, Ashish Dixit dixit@iastate.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15731; 25 Oct 94 23:39 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa15726; 25 Oct 94 23:39 EDT Received: from diablo.cisco.com (diablo.cisco.com [198.93.170.100]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id XAA14696 for ; Tue, 25 Oct 1994 23:36:53 -0400 Received: from [198.93.168.29] (dynaserv-d2-dynamic-29.cisco.com [198.93.168.29]) by diablo.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA21866; Tue, 25 Oct 1994 20:38:46 -0700 X-Sender: llang@diablo.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Oct 1994 20:35:13 -0700 To: dixit@iastate.edu, rolc@maelstrom.timeplex.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Larry Lang Subject: Re: Check out www.cisco.com via Mosaic. Especially check out info on the AIP, the HyperSwitch A100, and the CiscoFusion architecture. Also, be sure to check out RFCs 1483 and 1577. Larry At 7:16 PM 10/25/94, dixit@iastate.edu wrote: >Hi !! > > I am graduate student in computer scince at Iowa state >university. I am taking a course on Advanced computer >networking this semester and as a part of that I need to >write a paper on TCP/IP over atm. I just came to know that you >all have been working on this. It would be extremely kind of >you if you could send me some pointers where I could do >some readup on this. > >Thanks, > Ashish Dixit > dixit@iastate.edu ______________________________________________ Lawrence J. Lang Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134-1706 USA + 1 408 526 4638 Phone + 1 408 526 7666 Fax llang@cisco.com Email ______________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10708; 27 Oct 94 17:41 EDT Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa10704; 27 Oct 94 17:41 EDT Received: from enigma.acton.timeplex.com (enigma.acton.timeplex.com [134.196.22.57]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id RAA05216; Thu, 27 Oct 1994 17:29:37 -0400 Received: from maelstrom.timeplex.com (malis@localhost) by enigma.acton.timeplex.com (8.6.9/ACTON-SUB-1.0) with ESMTP id RAA00766; Thu, 27 Oct 1994 17:29:35 -0400 Message-Id: <199410272129.RAA00766@enigma.acton.timeplex.com> To: dixit@iastate.edu cc: rolc@maelstrom.timeplex.com, malis@maelstrom.timeplex.com Subject: Your IP over ATM information request In-reply-to: Your message of "Tue, 25 Oct 1994 21:16:51 CDT." <9410260216.AA00786@pv0f15.vincent.iastate.edu> Date: Thu, 27 Oct 1994 17:29:34 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Ashish, > I am graduate student in computer scince at Iowa state > university. I am taking a course on Advanced computer > networking this semester and as a part of that I need to > write a paper on TCP/IP over atm. I just came to know that you > all have been working on this. It would be extremely kind of > you if you could send me some pointers where I could do > some readup on this. Your request is actually more appropriate for the IP over ATM list, ip-atm@matmos.hpl.hp.com . However, to get you started, you should FTP to ds.internic.net and grab the following documents: IP over ATM: rfc/rfc1483.txt rfc/rfc1577.txt rfc/rfc1626.txt rfc/rfc1680.txt rfc/rfc1695.txt (if you are interested in network management of ATM interfaces) internet-drafts/draft-armitage-ipatm-ipmc-01.txt internet-drafts/draft-ietf-ipatm-framework-doc-00.txt internet-drafts/draft-ietf-ipatm-sig-01.txt Routing over Large Clouds (the topic on THIS list): rfc/rfc1620.txt (background on the problem) internet-drafts/draft-ietf-rolc-nbma-arp-00.txt internet-drafts/draft-ietf-rolc-nhrp-02.txt All of these documents have a number of references that may prove to be of value to you as well. Good luck! Cheers, Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04422; 31 Oct 94 11:28 EST Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa04416; 31 Oct 94 11:28 EST Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id LAA03473 for ; Mon, 31 Oct 1994 11:08:41 -0500 Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20913; Mon, 31 Oct 1994 09:40:39 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hiroshi Esaki Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14662; Mon, 31 Oct 1994 09:40:36 -0500 Date: Mon, 31 Oct 1994 09:40:36 -0500 Message-Id: <199410311440.JAA14662@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.eng.sun.com, colip-atm@necom830.cc.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.oz.au Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: Announcement of new mailing-list (correction) Dear for the persons who are interested in a new mailing-list (colip), ***** I wrote a wrong addresses for mailing-list (:-|) ***** The below is the correct one. We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- >> General Discussion: colip-atm@necom830.cc.titech.ac.jp >> To subscribe: colip-atm-request@necom830.cc.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ----------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04440; 31 Oct 94 11:29 EST Received: from maelstrom.timeplex.com by IETF.CNRI.Reston.VA.US id aa04436; 31 Oct 94 11:29 EST Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id LAA04026 for ; Mon, 31 Oct 1994 11:29:08 -0500 Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20389; Mon, 31 Oct 1994 09:01:17 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hiroshi Esaki Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14424; Mon, 31 Oct 1994 09:01:15 -0500 Date: Mon, 31 Oct 1994 09:01:15 -0500 Message-Id: <199410311401.JAA14424@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.eng.sun.com, colip@necom830.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.oz.au Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: Announcement of New Mailing-List Creation Dear everybody, Knock, knock, " TRICK or TREAT ? " We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- General Discussion: colip-atm@necom830.titech.ac.jp To subscribe: colip-atm-request@necom830.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ----------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08210; 31 Oct 94 17:17 EST Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08206; 31 Oct 94 17:17 EST Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa03618; 31 Oct 94 17:17 EST Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA00149; Tue, 1 Nov 1994 06:58:09 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00135; Tue, 1 Nov 1994 06:36:05 +1100 Precedence: list Received: from sirius.ctr.columbia.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23739; Tue, 1 Nov 1994 06:35:46 +1100 (from hiroshi@ctr.columbia.edu) Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id JAA20487; Mon, 31 Oct 1994 09:14:44 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hiroshi Esaki Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.6.7/8.6.4.788743) id JAA14496; Mon, 31 Oct 1994 09:14:42 -0500 Date: Mon, 31 Oct 1994 09:14:42 -0500 Message-Id: <199410311414.JAA14496@mimas.ctr.columbia.edu> To: int-serv@isi.edu, rsvp@isi.edu, ipng@sunroof.eng.sun.com, colip@necom830.titech.ac.jp, ip-atm@matmos.hpl.hp.com, rolc@maelstrom.timeplex.com, big-internet@munnari.oz.au Cc: mohta@necom830.cc.titech.ac.jp, nagami@isl.rdc.toshiba.co.jp Subject: Announcement of New Mailing-List Creation Dear everybody, Knock, knock, " TRICK or TREAT ? " We, Hiroshi Esaki and Masataka Ohta, would like to announce the creation of a new mailing-list focusing on study of extracting the capability of ATM without changing of the IP architecture. When you are interested in to join our discussion group, please subscribe to the mailing-list. The below is the brief announcement of this new mailing-list. Cheers, Hiroshi & Masataka ---------------- begin of statement ------------- 0. Name of the Mailing-list ----------------------- General Discussion: colip-atm@necom830.titech.ac.jp To subscribe: colip-atm-request@necom830.titech.ac.jp 1. Purpose and Goal ------------------- The goal of this mailing-list is to discuss the architecture of IP over ATM to keep the existing IP architecture as is and, at the same time, extract the full capabilities of ATM, that is, to have low-latent, high-bandwidth, QoS-assured communication. The study includes the implementation of ATM routers, which perform cell level relaying at the internetwork layer, which fits the existing layering model of the Internet. IP over ATM WG is proposing LIS (Logical IP Subnet) model for cell-wise communication within a LIS and ROLC WG is working on cell-wise communication among LISs. However, their proposal imply several changes to the IP architecture and it can not provide normal ARP nor autoconfiguration capability. Therefore, the architectural consideration providing autoconfiguration is also one of important aspects studied in this mailing-list. The current Internet is a collection of well-manageably-small link segments, which are connected by routers through connectionless internet layer protocol: IP. Within a link layer segment, hosts and routers may be connected either by connectionless or connection oriented link layer protocols. To fully extract the low-latent high-throughput and the QoS service oriented properties of ATM, the model takes care of not only the connectionless IP communication but also softstate reservation based QoS-assured IP communication related to RSVP or IPv6 flow mechanisms. 2. Suggested Documents ---------------------- + Internet-Draft : "Conventional IP over ATM" by M.Ohta,H.Esaki,K.Nagami draft-ohta-ip-over-atm-01.txt + Internet-Draft : "Connection Oriented and Connectionless IP Forwarding Over ATM Networks" by H.Esaki,K.Nagami, M.Ohta draft-esaki-co-cl-ip-forw-atm-00.txt ----------------- end of statement ----------------------