Robin, can you please synthesize a short version of this?
2010.11.23 вт 11:08:10 Robin Whittle: > Hi Wes, > > Thanks for your reply. In "Re: [rrg] rrg-design-goals-04 - we should > write something much better", (msg07574 in the archives, with each of > your paragraphs as one hard-to-read line) you wrote: > > >> Do you really support the goal that the solution be either Loc / > >> ID Separation (ILNP etc. not LISP, Ivip or IRON) or be compatible > >> with Loc/ID Separation? > > > [WES] Yes, I do, hence my vote in favor of publishing the design > > goals. I run a mobile network, so I know a thing or two about > > mobility schemes that use tunneled traffic and anchor points to > > maintain connectivity while the end host moves around without > > routing table updates. It works... However, the gear and > > encapsulation required and the scale tradeoffs to make it work are > > not optimal, and extending it and trying to make it scale to the > > rest of the Internet is exactly the wrong direction in my opinion. > > OK - I recognise there are problems with tunneling due to its > overhead, Path MTU Discovery problems and the potential for one > traffic packet to be split over two or more tunnel packets, raising > the risk of data loss due to a given rate of packet loss. > > Loc/ID Separation involves no tunneling. However, as far as I know, > there's no Loc/Id Separation approach to mobility which avoids these > fundamental problems: > > 1 - The MN (mobile node) can't be behind NAT. It needs a global > unicast address (Locator) so any other host can send it > packets directly, and without any preliminaries. > > 2 - Every time the MN (mobile node/host) changes its CoA (current > "Care of Address" in the current system, in Loc/ID Sep.: > "Locator") it has to do several things: > > a - Securely tell all its CHs (correspondent hosts) of its > one or more new Locators and about which ever ones it > has just relinquished. > > b - Securely update the centralised ID->Loc mapping system > with the new Locator information so other hosts can > initiate contact with it. Depending on the design > of the Loc/ID Sep. architecture, this may be the same > thing as DNS or the DNS server also needs to be updated. > (With Loc/ID Separation, every host needs a DNS entry > as well as an entry in a potentially separate ID->Loc > mapping system.) > > Similar problems apply to the current LISP approach to mobility: > > http://tools.ietf.org/html/draft-meyer-lisp-mn-04 > > (This v04 version from 2010-10-25 is a month old and contains > the first substantial changes since v00 of 2009-07-01. > I haven't read these changes, but a quick scan of the DIFF2 > gives me the impression that it hasn't changed in ways which > affect my critique of LISP Mobile: > > http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html ) > > In the Loc/ID Separation world, maybe there will be no NATs - this is > an updated version of the IPv6 Internet, not something based on the > IPv4 Internet - since no Loc/ID Separation system can work on IPv4 for > reasons including inefficient use of address space and there being no > method of conveying Loc and ID in existing packet headers. > > Point 2 is more fundamental. I argue it can't be solved and that it > is therefore better to adopt TTR Mobility, where there is a 2-way > tunnels, established from the MN to a (typically) nearby TTR, which > acts as an ETR in the Core-Edge Separation scheme (LISP or Ivip, > though I think IRON uses TTR Mobility principles already) and handles > outgoing packets too. With TTR Mobility: > > http://www.firstpr.com.au/ip/ivip/#mobile > > the MN can be behind NAT and/or on a TTR Mobile address, in any > combination and depth of recursion. > > If you stick with Loc/ID Separation, or LISP-mn, then there's no way > the MN is going to be able to securely update the Locator information > in multiple CHs all round the world in a timely or efficient fashion. > (You could offload the work to a separate server to fan out the > updates, but this raises delay and scaling problems, since only the MN > has the nonces for each session with another CH.) > > Each such update needs to involve strong crypto or a nonce or similar, > since it will come to the CH from an IP address or Locator which the > MN has no previous association with or knowledge of. Assuming the MN > has just lost one CoA (AKA Locator)and instantly gained another, user > packets from the CHs to the MN will be sent to the old CoA/Locator > until the update is completed. Only then will traffic, such as VoIP, > be received again by the MN. > > If the CH is mobile too and it changes its CoA/Locator at about the > same time, they will both have to detect this and wait for the other > host to update its DNS or ID->Loc mapping in the global mapping > system. Then they can use this (with this mapping system, with the > likely delays and risk of query or response packet loss which is > inherent in in any global query server network) to re-establish > communications. > > So, every time the MN gets a new CoA, it needs to send out a flurry of > packets to its various CHs - however this is determined. I guess a 5 > minute cache time or similar would reduce the number of CHs to > contact, but this would force all CHs to revert back to DNS or ID->Loc > global lookup to continue or start a new session if there was more > than a 5 minute break between packet exchanges. > > It would be bad enough doing this from a DSL or fiber-connected > service. Doing it via potentially slow, potentially high latency, > potentially costly and potentially unreliable 3G or GPRS radio links, > with a compact battery operated device, would be much worse. > > Also, the global DNS and ID->Loc lookup systems (which may both be > done via DNS or similar) will have to update their central > authoritative server information every time the CH gets a new CoA. > > These rapid changes mean that all DNS and ID->Loc queries need to go > to the one or more authoritative servers - they can't be cached at > all. To cache them for even 10 seconds would result in a 10 second > delay in the ability of two MNs to reconnect after they both get new CoAs. > > So the entire DNS and ID->Loc lookup system is global and uncachable. > > The global infrastructure and the central servers get a hammering. > You can make multiple authoritative servers to spread the load and > generally shorten the delay, if the query somehow automatically goes > to the closest server. But then you increase the workload for the > update every time the MN gets a new CoA/Locator. > > I think its much better to have the MN tunnel from its one or more > CoAs to a typically nearby TTR (Translating Tunnel Router). The MN's > address or address range is mapped in the CES system (such as Ivip or > perhaps LISP) to use that TTR as an ETR. So only the MN->TTR tunnel > establishment, from the new CoA to the existing TTR, is required to > continue communications from the new CoA. > > There's no impact on CHs at all, or on DNS, or on the CES system's > mapping database each time a MN gets a new CoA. Only if the new CoA > is far from the current TTR - such as 1000km or more - would it make > sense for the MN (under the guidance of the TTR system) to find a new > TTR (which can be done while the old TTR is still being used) and then > to switch the mapping to the new TTR. So mapping changes would be > very infrequent and there would be minimal effort in establishing a > tunnel to the current TTR, from the new CoA, every time the CoA changes. > > This leaves us with the burden of tunneling, but typically it will be > to a TTR which is nearby. > > Changes to CoA can happen very frequently, even without the MN moving. > The 3G network might bump it to a different base-station which uses a > different IP gateway. Base station capacity limitations or RF > propagation and interference changes might end the session. A new, > cheaper, faster WiFi link might become available, and the MN gets a > CoA on that, including behind NAT. Just driving past an open-access > WiFi system of a cafe could cause this. Likewise boarding a train, or > aircraft - or driving through a tunnel, or entering a building. > > There shouldn't be a flurry of updates to CHs and the mapping system > ever time a cell-phone connects automatically to a WiFi system or > whatever. But that is what would happen with Loc/Id Separation or > LISP-mn. > > I think the difficulties with tunneling are not prohibitive, but that > the problems I mentioned with Loc/ID Separation mobility and LISP-mn are. > > > >> If so, can you or anyone else think of a way any Loc/ID > >> Separation architecture could work on IPv4? > > > [WES] Well, based on what I read I believe that ILNP can, but I > > understand that you don't, nor do you buy the explanation to the > > contrary. I don't wish to re-debate that with you because I doubt > > it'll change either of our minds. > > ILNP can only work on IPv4 with some new kind of header information. > It seems that some, many or all routers in general - or DFZ routers in > particular - are not able to handle packets with new header options > with their normal efficiency. So unless you factor in upgrading all > these routers, ILNP can't work with IPv4. If you have a magic wand to > upgrade all the IPv4 DFZ routers, such as to recognise new packet > formats, then there's lots more things we could do regarding scalable > routing. Loc/ID Separation would not, in my opinion, be the best > approach to take. > > > > However, let me be absolutely clear: I. don't. care. whether it > > will work on IPv4. It's too little, too late. We're out of address > > space for IPv4. I can't number my 50 million mobile customers with > > IPv4, most emerging economies can't number their entire populace > > out of IPv4 the way that the current first-world countries have > > done, and we can't number the smart grid out of IPv4, to say > > nothing about the other machine-to-machine and internet of things > > applications that are poised to dramatically increase the steepness > > of the routing table growth curve. I'll concede that some of the > > route-scale solutions proposed here might be able to extend IPv4's > > useful life by allowing for segmentation and reuse of the space, > > but with IPv4 exhaustion likely happening in the next 3-6 months, > > they're not going to be implemented in time. Further, for them to > > be better than a NAT44(4) in that regard, they have to restore > > seamless end to end connectivity (and as far as you're concerned, > > do it with out application or CPE changes). Like it or not, IPv6 > > (and specifically IPv6-only) is going to be a reality. 5+ years ago > > it might have made sense to have a solution for IPv4, but at this > > point I'd rather focus on IPv6. If we get a solution for IPv4 for > > little incremental work, great, but I don't want to delay the work > > to force that issue to get resolved if we have a workable solution > > for IPv6. In the normative language of the draft, I view an IPv6 > > solution as REQUIRED, an IPv4 solution as somewhere between DESIRED > > and OPTIONAL. > > I agree that expansion of mobile IP to encompass the billions of > people who want and need it must involve IPv6. (This is on the > assumption that it won't do to give all these devices simply a behind > NAT IPv4 form of connectivity. Maybe this assumption is not true - in > which case IPv6 won't be needed.) > > I guess this will enable the devices to access the IPv4 world via a > NAT box and tunneling through the IPv6 access network and mobility > system. This rules out direct VoIP with the IPv4 world, but it would > work via an intermediate server which the MN established a tunnel to > from behind its IPv4 NAT box. > > So I expect (if the above assumption is true) that IPv6 will be used > to a significant degree for mobile networks in the next 5 to 10 years. > That would drive the service industry for mobile users to get native > IPv6 servers. It may also drive non-commercial users to get native > IPv6 connectivity at home so they can send packets straight back and > forth between their and their cellphone (music player, PC etc.) > > But giving every cell phone a global unicast IPv6 address, via any > means, including especially a mobility system which means the device's > applications use the same IP address no matter what access network > they are using, would enable each device to do direct VoIP to any > other IPv6 device. That would reduce the wireless networks to > providers of IP connectivity, since it would be trivial to have a VoIP > application on the cellphone which communicated directly with the > stable (portable and usable via all access networks) IPv6 address of > the correspondent device. (Phone numbers would be replaced by IPv6 > addresses - or by DNS entries for these addresses.) > > I am not sure there is an impetus for 3G operators to do this, since > it would enable many people to bypass their voice services, which are > presumably charged for at a higher rate than whatever they would > charge for the VoIP packets. > > The impetus for global mobility is directly for the end-user's > benefit. So I expect global mobility companies to provide such > services by TTR Mobility, even when the 3G operator doesn't want its > customers to have this. Then again, if one 3G network prevents global > mobility and the other allows or provides it, many customers would > those the other. > > I think the choice for mobility will be between: > > 1 - Existing MIPv6 arrangements, which either require updated stacks > (I think) in CHs to minimize path length problems via the one > Home Agent, or reliance on existing stacks in CHs and the Home > Agent, which involves potentially very long paths when the MN is > on the other side of the world. > > 2 - LISP and its current LISP-mn approach, which has the problems > listed above, plus the fundamental problems with LISP such as > the difficulty or impossibility of ITRs scalably determining > which ETRs can actually get packets to the destination network. > > 3 - Loc/ID Separation, such as ILNP or Name Based Sockets. This > will only work with CHs which have suitably upgraded stacks and > applications. So this is a non-starter. Even if this hurdle was > overcome, the recipient host will typically need to delay > replying to the initial packet while it does an ID->Loc lookup, > since it can't take on trust the ID and Loc values which are in > the source fields of the initiating packet. > > http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html > > Then, there are the fundamental delay and scaling problems > mentioned above every time the MN gets a new CoA - and the > MN not being able to use a CoA behind NAT. > > 4 - TTR Mobility, with either Ivip or LISP as the CES system. > (Or perhaps IRON, which apparently incorporates some principles > of TTR Mobility - I haven't read the latest drafts.) > > If you choose to build or use something like Ivip, then you can > use what I am calling ZOTv6 - Zero Overhead Tunneling for IPv6. > This is Sampo Syreeni's suggestion and I will probably write up > a quickie version of it for the RRG list sooner rather than > later. It can't work with LISP, since it doesn't carry the ITR's > address with the tunneled packet - and LISP's protocols involve > this and other information being sent along with the tunneled > packet. But it is good for Ivip since Ivip doesn't require the > ETR to know the address of the ITR which is tunneling packets to > it. > > ZOTv6 is for the ITR -> ETR tunnel. You still need to use one > of a variety of (typically encrypted) two-way encapsulation-based > tunnel techniques for the MN <--> TTR tunnel, which the MN always > establishes, including from behind NAT or from a TTR Mobility > provided address. > > ZOTv6 requires an elaboration for the management of the ETR and > more complex mapping data. But for Ivip, the ITRs are not > having to choose between multiple ETRs, so the ITR's job is still > quite simple, compared to what a LISP ITR would have to do. > > ZOTv6 and the quite different ZOTv4 I have developed, inspired by > Sampo's most insightful suggestion, both involve some Path MTU > Discovery gotchas. For packets below a certain globally agreed > length, there's no extra work to be done. For packets which are > longer than this - say longer than 149x bytes - the ITR must > initiate a brief two-way protocol with each ETR it is sending > packets to - when a packet is being sent which is longer than > the already established minimum MTU to that ETR, but not above > any maximum which has been established so far. This is a PITA, > but I can see a way of doing it. The ITR and ETR occasionally > communicate to manage the ITR's estimate of PMTU to the ETR. > This enables the whole system to handle jumboframes (~9k byte > packets) across the DFZ if and when this becomes possible. > > > >> Can you or anyone else think of a way it could work even on IPv6 > >> without requiring a major rewrite of application code, and in > >> some cases changes to application protocols themselves? Ran > >> claims ... but ... I decided it probably couldn't be. Ran didn't > >> even attempt to show how it could be done. Tony tried (msg07111) > >> and gave up ... > > > [WES] As you say, you've been over this, and I'm not going to be > > any more successful at debating it with you than the author of the > > draft. > > I don't recall Ran debating it. Nonetheless, the claim that ILNP > works with existing IPv6 apps was accepted by most people, myself > included, until I tried in July this year. The claim persists, > despite my objections, in the soon to be RRG Report: > > http://tools.ietf.org/html/draft-irtf-rrg-recommendation-15#section-12.1.2 > > ILNP can be implemented such that existing applications (e.g. > applications using the BSD Sockets API) do NOT need any changes > or modifications to use ILNP. > > > > You obviously believe that host changes are less possible > > than expecting providers like me to swallow hard and implement > > another round of costly infrastructure to solve this problem, and > > I'm not going to be able to convince you otherwise, but I'll still > > make my opinion known since you asked. A very significant part of > > the reason why IPv6 has taken so long to deploy and there is > > resistance to things like ILNP is that the Internet infrastructure > > has gotten very sclerotic and resistant to change. > > Yes - its the world's most entrenched IT system and its big feature is > the ability to communicate between any hosts. This has taken a hit > with NAT, with behind-NAT hosts being second-class citizens which are > not able to communicate directly with each other - but they can still > communicate with any server on the IPv4 Internet. > > Trying to introduce changes to the existing system, including using > the IPv6 Internet instead, leads to all sorts of difficulties which > mean most users won't bother and will soldier on with IPv4 as it is today. > > > > I'd rather not > > reinforce that by enabling people to continue assuming that host > > changes are off limits and the network providers should be solely > > responsible for keeping the internet working (and all the while > > racing each other to the bottom on prices for services). > > In an ideal world *perhaps*, we could convince all the people who > write software for PCs, cellphones etc. to write new versions of their > programs to handle a new stack API and a new set of basic Internet > protocols. This would be a very tall order indeed, since they would > need to test and maintain their code to work with and without a new > kind of stack, operating with their own code and other programs in > remote machines which both did and didn't have the new features and > which did and didn't run on a host with the new stack. This would be > a complete nightmare. > > "*perhaps*" means if we somehow were convinced that the initial delays > and other overheads inherent in Loc/ID Separation were a price worth > paying for its benefits (msg07017). > > It also means deciding the generally longer delays and less efficient > operations required by Loc/ID Separation when the MN changes its > Locator are acceptable. > > To use TTR Mobility, you don't need new routers. You, or someone > else, needs to develop a bunch of protocols and software to implement > them. The ITRs, ETRs/TTRs and mapping system can all be done with > COTS servers. These functions don't need to be done by Cisco/Juniper > routers. You would also need to develop tunneling and management > software for each particular type of mobile device your customers use. > Assuming your routers, mobile networks and mobile devices can do > IPv6, it "just" needs a lot of software development. Competent > programmers could figure it out from reading the TTR Mobility and Ivip > stuff. You don't need to wait for the IETF. Hopefully my exposure of > this stuff means none of it can be patented - or that such patents > would not hold up in court. > > > >> There's no tearing hurry about scalable routing. > > > [WES] Hi, my name's Wes, and I'm an [token] operator. You don't > > know me, but I work for a large-ish US-based ISP in the DFZ, > > Sprint - indeed a large operator! > > > and we > > happen to be very much interested in scalable routing... RIGHT > > ZARKING NOW, so that something might be implemented before we have > > to spend another XX million USD in a few years to buy > > $router_vendor's next generation linecard and memory to hold the > > routing table. > > OK. Let me write something better: > > With the current pace of RRG official recommendations, LISP > development and the likely impossibility of testing and developing > ILNP or any other Loc/ID Separation architecture to the point where > anyone might make a serious investment in deploying it, I would > say there's no urgency this month or the next, and probably not > next year or to 2013 or so, to actually come up with a detailed > set of protocols and operating code which genuinely solves the > scalable routing problem, for IPv4 or IPv6, including especially > providing proper global mobility with generally VoIP-compatible > response times and typically short path lengths. > > This is because there's no way LISP, ILNP or whatever will actually > be seriously invested in or committed to in a way which will > impose costs on users. > > In that time, the IPv4 DFZ will grow, and perhaps grow more rapidly > than in the last 5 years, despite the imminent 2nd Great > Depression. > > I am not sure how close your routers are to hitting a wall with > the IPv4 DFZ's 330k routes: > > http://bgp.potaroo.net/ > > but as long as they can cope with 600k routes, then I guess you > should be fine for another 4 or 5 years. > > There's no way the IPv6 DFZ routing table is going to become > too large for your routers in the foreseeable future - say in the > next 10 to 15 years. (Unless the limitation is the total number > of IPv4 and IPv6 routes - in which case the problems can't be > separated and my analysis would be different.) > > As long as you and a bunch of other operators are running mobile > and DSL/fiber access networks, there's no significant problem with > the number of IPv6 DFZ routes growing beyond 50k or 100k or > whatever. The only scaling difficulty would arise if there were > lots of end-user networks (EUNs) wanting, getting and advertising > their own IPv6 PI prefixes AND if you really wanted or needed to > exchange packets with those EUNs. There would need to be a lot of > such EUNs doing this before the problem got to the 200k, 300k, 600k > or whatever level where I assume you begin to hit limits with the > routers. > > That growth in EUNs advertising PI prefixes has nothing to do with > mobile or DSL/fiber access networks, even with billions of > customers. You might have part of your 3G/4G network supporting > 50 million customers, each with one device. But it will only > involve one or a few prefixes in the IPv6 DFZ. So I can't see how > 3G/4G ISPs alone will ever cause the IPv6 DFZ routing table to > grow to a problematic size. > > The only reason in the foreseeable future (to 2020) I can see for > large numbers of EUNs wanting IPv6 connectivity is to serve the > growing millions of mobile users on the necessarily IPv6 mobile > networks Sprint and other such companies will presumably be > deploying. (This is on the assumption that you can't sell a > mobility service with purely behind NAT IPv4 connectivity - and > that you really must have a global unicast IPv6 address for each > MN. I am not convinced this assumption is true or will become > true in the foreseeable future.) > > So my sense of there being "no tearing hurry" is this: > > It doesn't matter much whether I devote my life to developing > Ivip drafts and software in the next year or two, since there's > no chance that ILNP (or any other Loc/ID Separation architecture > or LISP will be developed to the stage where some networks or > users might make a big investment in them. > > So when the time is right, people will discover, or re-invent, > TTR Mobility and Ivip. > > If I thought the IETF could mandate a change to LISP, or to > ILNP etc. and that this mistaken (IMHO) decision would be > binding on all Net users and so disastrously wrong and costly, > then I would say there is a big hurry right now to raise > awareness of what is wrong with these approaches, in part by > fully developing something better (Ivip & TTR Mobility, in my > view, or IRON, or whatever it is which someone thinks is > better.) > > However, this statement in general about there being no tearing > hurry about scalable routing, including mobility, is just for my > vision of architecture developers in the next year or two. > > Companies such as Sprint need to plan now what they will be doing > in 2016 to 2020. So there is a hurry for them. > > Likewise anyone who wants to develop a commercial TTR-style > global mobility service. There's no standards or technical > impediment to creating such a service today, for IPv4 or IPv6. > The customers would pay a TTR company for a TTR service and use > any access network at all, including one or more 3G providers, > free WiFi services and their own WiFi extensions of home DSL / > fiber / HFC for their Internet access. > > There could be multiple TTR companies, each with their own global > network of TTRs, their own tunneling software for different types > of MNs, their own DITRs at the globally dispersed TTR sites. > Each such network could operate with its own private protocols, > without any reference to IETF standards for scalable routing. > > For a number of reasons it would be better if they used common > protocols - but a bunch of such services could co-exist > perfectly well, even if they all used their own code and their > own unique protocols. Any customer of such a company could have > their stable IP address wherever they go, and there would be > generally optimal paths to all other hosts, including those on the > same and on other TTR systems. > > > > This is especially true if we do that upgrade once > > or twice more only to then have to spend the same or more when > > someone finally gets around to implementing a route scale solution, > > especially if implementing the proposed solution requires the > > network to change instead of hosts. So I trust you'll forgive me > > for not trusting your unsupported assertion on how much time we do > > or don't have to solve this problem. > > OK - I apologise for writing something which implies that you and > companies such as yours shouldn't be concerned about scalable routing > any time soon. > > I think the best approach is TTR Mobility with Ivip. While perhaps it > would make sense to have existing or future Cisco/Juniper routers > doing some of the work, I think that in the initial stages and > probably in the long-term future, COTS servers, including blade > servers, will be a much better set of devices to perform the ITR, ETR, > TTR and mapping server functions. > > So I think you don't need to spend a cent on upgrading your routers to > achieve what I have in mind. > > > > Hopefully that explains why a number of my messages to this list > > have been to try to move things forward, not prolong (or worse, > > recycle) debate. I'd like to see some of this stuff move towards > > implementation phase independent of whatever politics have > > destabilized this group, because running code will expose all sorts > > of design flaws much faster than debate on an email list ever will. > > I agree. I would be really happy if you and other people with your > expertise and responsibilities took a close look at TTR Mobility and > Ivip and let me know, privately or in a list such as this, what you think. > > I have outlined what I regard as show-stopping problems with LISP, > LISP-mn and Loc/ID Separation of all kinds, including ILNP - and I > don't think these critiques have been refuted. As far as I know, TTR > Mobility is the only way of doing global mobility, for IPv4 or IPv6, > with lightweight VoIP-friendly fast responses to new CoAs, and with > generally optimal path lengths. > > TTR Mobility could work quite well with LISP, even if its mapping > system was quite slow to update all the ITRs. It would work better > with Ivip, and I will soon write up ZOT - how Ivip can work with > ordinary packets, using ordinary routers, no longer than the original > traffic packet, in the ITR -> ETR tunnels. ZOT can't work with LISP - > and LISP ITR->ETR/TTR tunneling for IPv6 involves a complete outer > IPv6 header, a UDP header and a LISP header. This is a lot of > encapsulation overhead, especially for a VoIP packet which only > carries 20 bytes or so. > > > > Having to evaluate running code and make a choice between multiple > > different options that exist in the output of this group is a > > problem that I would very much like to have, and I see no way that > > revisiting arguments that you've apparently been having with this > > group since 2007 gets us anywhere closer to that goal. > > > > Thanks Wes George > > I would welcome your feedback on TTR Mobility and Ivip. > > Its counter-intuitive that valuable solutions might come for free from > some bloke in Australia you haven't met, rather than the Cisco or > Juniper folks who you have paid millions or billions of dollars to for > their essential and generally excellent routers. But until someone > shows that my proposals contain fatal flaws, this counter-intuitive > notion hasn't been disproven. > > - Robin > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg