[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Taxonomy: 25 questions



Short version:      Two questions which weed out the impractical
                    proposals and leave us with five potentially
                    practical map-encap proposals.

                    Then, 23 questions which lead to a
                    taxonomy within which these five sit.
                    I think the answers to these help us
                    to understand the problems and
                    potential solutions.

Here are some questions which I think provide useful insights about
the five potentially practical map-encap schemes, and some schemes
which are impractical, at least according to my criteria (10) in:

  Re: [RRG] What does incremental deployment mean - 2 questions
  2008-03-22 http://psg.com/lists/rrg/2008/msg00957.html

I think criteria such as this must be met by any scheme which would
have a hope of being deployed widely enough to significantly reduce
the routing scaling problem.

These questions should all be answerable by the developers of each
scheme without much debate.  I have answered for other proposals
where I felt confident I could give the right answer - but I may
have made mistakes.

Although many of the questions are strongly linked to outcomes such
as "deployability", "security" etc. none of them, as far as I know,
involve making value judgements about the performance of each
proposal, other than rough evaluations of mapping update time and
delay times for initial packets.

Links to these proposals are at the RRG Wiki:

http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup


[Q01]

Does the scheme require host changes in order for hosts to
participate in it?  This includes adopting dual stack IPv4/v6 and
applications which in fact use IPv6. (A No for this answer means the
scheme could work, in different versions, with both IPv4 and IPv6.)


  APT                              No.

  AIRA                             ?

  CRIO                             No?

  LISP-ALT/NERD                    No.

  IPvLX                            Yes. "long-term IPv6/IPv4
                                   coexistence, with IPv6 addresses
                                   serving as identifiers."

  Anything proposed by
  Heiner Hummel.                   Yes, as much as I understand
                                   his proposals, which seem to
                                   involve radical changes to
                                   routing and addressing.

  ISATAP                           Yes - IPv6.

  Ivip                             No.

  Six/One Router                   Yes - IPv6.

  Six/One                          Yes - IPv6 with host changes to
                                   implement Six/One.

  TAMARA                           Yes - IPv6.

  TRRP                             No.

I think those schemes above for which the answer is Yes should be
mentioned in the Taxonomy in this respect, but not considered any
further - unless perhaps in a completely separate section reserved
for long-term plans not restricted by practical considerations of
being deployable in currently foreseeable circumstances.

Trying to solve the IPv4 routing scaling problem by migrating users
to IPv6 addresses only (no IPv4 address at all) is nowhere near a
practical solution.  There is no significant adoption of IPv6 at
present amongst general Internet users and no such user could
survive for a moment without their IPv4 address.  Furthermore, there
is no routing scalability problem in IPv6 now, so IPv6 routing
scalability, lack of multihoming (now /48 PI space is available)
etc. is not a problem restricting the adoption of IPv6.  So a
proposal which proposes to solve only the IPv6 scaling problem is of
no importance in the foreseeable future - only in the long term if
and when IPv6 is ever really widely used.


[Q02]

For the proposals for which the Q01 answer was No, do they aim to
provide a mechanism by which there is no loss of connectivity for
any hosts, as the system is deployed, including for communications
to and from networks with no upgrades?

  APT             Yes.  However, there are limitations on the
                  support for EIDs, which might be resolved if APT
                  used allowed a somewhat different type of link
                  between APT networks, so there would naturally be
                  only one global APT system, rather than multiple
                  APT islands.  See my message "APT: no need for
                  islands?" 2008-03-12:
                  http://psg.com/lists/rrg/2008/msg00734.html


  AIRA            No - there are two separate namespaces for
                  Identifiers and Locators.  That means that hosts
                  using the new Identifiers for their own addresses
                  won't be able to communicate with hosts which are
                  not upgraded.

  CRIO            This is a complex proposal I have very little
                  understanding of, which has not been discussed
                  much recently in the RRG, and for which no RRG 8
                  page summary and analysis has been prepared.
                  AFAIK, it involves radical address changes
                  and so I think the answer is No.

  LISP-ALT/NERD   Yes - "Proxy Tunnel Routers".


  Ivip            Yes - OITRDs (Open ITRs in the DFZ, formerly
                  "anycast ITRs in the core".

  TRRP            Yes, but I can't recall exactly how at present.


This leaves five proposals which have a chance of meeting my message
957 (10) criteria (ignoring LISP-CONS, which I think is on the
back-burner):

  APT
  Ivip
  LISP-NERD
  LISP-ALT
  TRRP

Since all other proposals have no hope of being practical, I think
rest of the Taxonomy should only consider these five proposals - and
any new proposals or variants which pass muster in the above two
questions.


Here are some Taxonomy questions which I think are illuminating:


[Q03]

How is mapping delivered to ITRs?

  APT        Hybrid push-pull.

             Push to Default Mappers.
             Pull to caching ITRs from Default Mappers.

  Ivip       Hybrid push-pull.

             Push to full database ITRs (ITRDs) and to full
             database Query Servers (QSDs).

             Pull to caching ITRs (ITRCs), ITR functions in
             sending hosts (ITFHs - not behind NAT) and
             caching Query Servers (QSCs) from QSDs and QSCs.

  LISP-NERD  Pure push.  (Not expected to be scalable to
                          hundreds of millions or billions of
                          EIDs.)

  LISP-ALT   Pure pull.

  TRRP       Pure pull.


[Q04]

How fast can an end-user's mapping change be sent to all ITRs?

(See my message: "Mapping model discussion - push, pull, hybrids
and notify", 2008-03-11: http://psg.com/lists/rrg/2008/msg00707.html
and "Notify = "proactive" updates; flexible placement of full db
ITRs & query servers" 2008-03-13 message 757.)


  APT        Slowly.  Depends on slow flooding protocol and the
             ability of Default Mappers to Notify ITRs of
             changed mapping.  No times are mentioned, but I
             recall the earlier version, with BGP flooding,
             anticipated the mapping not changing for days or
             months.

  Ivip       Fast - ideally 5 seconds.  Fast push to ITRDs and
             QSDs.  Immediate Notify from QSDs (via any intermediate
             QSCs) to all ITRs which might be sending packets
             for the micronet with changed mapping (according
             to the caching time of map replies given out by
             the QSD): ITRCs and ITFHs.

  LISP-NERD  Slowly.  Depends on frequency by which central
             servers files are updated with user mapping
             changes and then on how frequently each ITR
             downloads all the most recent files, or update
             files.

  LISP-ALT   In practical terms, slowly, such as minutes or
             tens of minutes.  Depends primarily the caching
             time of map replies - and shorter times means
             more queries, responses etc.  There is no Notify
             (ITR cache invalidation) mechanism.

  TRRP       As for LISP-ALT, since both use a global query
             server network.  TRRP doesn't have a workable
             Notify system.  It has a limited cache invalidation
             system where an unreachable ETR leads to an ICMP
             message to an ITR, which can then issue a new
             mapping request.

[Q05]

Would end-users pay for mapping changes:

  APT        I don't think so, but ISPs would be annoyed at
             constant flurries of mapping changes tying up
             their flooding system.

  Ivip       Yes - a few cents, I guess.

  LISP-NERD  I guess not, but again, if whoever runs the
             central server gets sick of some end-users
             constantly changing their mapping, some fees
             would be charged.

  LISP-ALT   No.  The end user runs their own authoritative
             query servers in a pure pull global network.
             They can change mapping as often as they like
             without burdening anyone.  But what about the
             burden of mapping replies with short caching
             times?

  TRRP       As for LISP-ALT.


[Q06]

Does the end-user have to pay for traffic directed to their micronet
/ EID prefix?

  APT        ?

  Ivip       Yes - the RUAS runs the OITRD ITRs in the DFZ, and can
             be expected to charge end-users according to what
             traffic these ITRs handle.  However, this is probably
             just a server sitting at an Internet exchange, so the
             cost would be a lot less per gigabyte than for
             connectivity via an ISP.

  LISP-NERD  } Not with current proposals - but these proposals
  LISP-ALT   } have no business plan for Proxy Tunnel Routers

  TRRP       ?


[Q07]

What information is contained in each micronet's mapping (each EID
prefix's mapping)?

  Ivip       The ETR address.

  APT        } One or more ETR addresses, with weights and
  LISP-NERD  } priorities to enable each ITR to implement
  LISP-ALT   } multihoming service restoration and/or
  TRRP       } inbound load sharing (explicit TE).


[Q08]

Therefore, what functionality is required in the ITR and ETR?

  Ivip       No reachability functionality, except as a by-product
             of Ivip's inbuilt PMTUD and fragmentation management
             system (yet to be finalised, but see my PMTUD-frag
             page).

  APT        } ITRs must individually determine reachability
  LISP-NERD  } of each ETR and whether the ETR can reach the
  LISP-ALT   } destination.  Also, I think in LISP, the ETR
  TRRP       } may, or must, somehow tell ITRs about reachability
               of other ETRs which are in the mapping.  (But
               how does the ETR know exactly what mapping the
               ITR has??)

[Q09]

Therefore, is the system a monolithic approach, permanently
integrating reachability and multihoming service restoration
decision-making functions in the map-encap scheme, or enabling and
requiring end-users to supply their own reachability and
decision-making systems?

  Ivip       Modular = non-monolithic.

             End-users must do their own reachability testing
             and make their own decisions on how to restore
             service.  (They would typically do this by hiring
             some company to do it however they want it done.)


  APT        } Monolithic system.  Since all these do not
  LISP-NERD  } get end-user mapping changes to all ITRs
  LISP-ALT   } quickly, the map-encap system must do all
  TRRP       } reachability testing and make all decisions.
               ITRs and ETRs must do this, using relatively simple
               mechanisms and mapping data which are hardwired into
               the entire map-encap system.  This will not
               satisfy all needs of end-users, since it is
               impossible to anticipate all the ways end-users might
               want to test reachability and since it is impossible
               to define exceedingly complex or extensible
               arrangements into the map-encap scheme itself.
               Also, ITRs acting alone are a poorly scalable and
               inefficient mechanism for testing reachability and
               for making decisions.

[Q10]

Does the proposal tackle the PMTU and Fragmentation problem?

  APT        No.

  Ivip       Yes - but I haven't finalised it.

                http://www.firstpr.com.au/ip/ivip/pmtud-frag/


  LISP-NERD } Yes, but this is subject to critiques which have
  LISP-ALT    not yet been answered:

               http://psg.com/lists/rrg/2008/msg00678.html
               http://psg.com/lists/rrg/2008/msg00687.html
               http://psg.com/lists/rrg/2008/msg00692.html
               http://psg.com/lists/rrg/2008/msg00694.html etc.

  TRRP       No.


[Q11]

Does the system involve explicit TE?

  Ivip       No.  Load sharing must be done by splitting the traffic
             over multiple micronets (each of which can be a single
             IP address) and then mapping the micronets to different
             ETRs, so the traffic is split over multiple links to
             the provider networks with these ETRs.

             This can be changed (for a small fee per update) in
             real-time, which may make it more useful - at least
             in some settings - than the slowly controlled, explicit
             TE functions of the other schemes.


  APT        } Yes - they all use a similar method of specifying
  LISP-NERD  } the share of traffic to be sent to two or more
  LISP-ALT   } ETRs, by each ITR operating independently - except
  TRRP       } that in the case of APT, the Default Mapper makes the
               splitting decision and tells each querying ITR a
               single ETR address to use.


[Q12]

Does the system provide complete portability of the end-users mapped
address space?

  Ivip       } Yes - as long as the end-user network uses an ISP
  APT        } which has an ETR and which will accept outgoing
  LISP-NERD  } packet with the source address being within the
  LISP-ALT   } end-user's micronet (EID prefix).
  TRRP       } For ISPs which don't do this, Ivip's mobility
               system, which requires the end user to be a
               customer of a TTR network, will provide forwarding
               of the end-user's outgoing packets.


[Q13]

Does the system aspire to support mobility, and if so, how?

  Ivip       Yes, without any extra complexity for the basic
             map-encap requirements for solving the routing
             scalability problem. See:

                http://www.firstpr.com.au/ip/ivip/#mobile

             which has new diagrams.  This is a new approach to
             mobility.  See message 994 for using these "mobility"
             techniques as a lightweight approach to multihoming
             a fast, generally reliable, but expensive fibre link
             for a moderate sized commercial end-user network.

  APT        } No specific mechanisms for supporting new
  LISP-NERD  } approaches to mobility.  Should work fine
  LISP-ALT   } with existing mobile-IP, although any interactions
  TRRP       } have not yet been explored in detail.


[Q14]

What is the granularity of address management?

  Ivip       IPv4 addresses or IPv6 /64s.  Within these
             increments, each micronet has an arbitrary starting
             point and length (except that the maximum length
             of an IPv4 micronet is 2^24).  This is not yet in
             the Ivip IDs, but is described in message:
             http://psg.com/lists/rrg/2008/msg00958.html

  APT        } Not yet clear, but I think they can all support
  LISP-NERD  } EID prefixes starting at any IPv4 address or
  LISP-ALT   } IPv6 /64, in CIDR prefix format and therefore
  TRRP       } powers of two lengths on binary boundaries.


[Q15]

What role might the scheme play in the IPv4 address depletion
problem, other than the long-term possibility of helping make IPv6
more attractive in various ways, including by providing a solution
to the multihoming, routing scaling problem etc. in IPv6?

  Ivip       Intended to help via lower-cost, more flexible,
             management of finer slices of address space, including
             individual IPv4 addresses.  This will enable more
             end-user networks to have MH, portability etc.
             and will enable IPv4 space to be utilised significantly
             more efficiently.  This capability does not involve any
             additional complexity over what is required for solving
             the routing scalability problem.

  APT        } I think they would all be nearly as good as Ivip
  LISP-NERD  } for helping improve IPv4 address utilization.
  LISP-ALT   } Ivip's finer control over micronet length makes it
  TRRP       } somewhat better in this regard.

               I think none of them have better IPv4 address
               utilisation as an explicitly goal.

               Nonetheless, any proposal which solves the routing
               scalability problem for IPv4 must surely be
               improve the utilization of IPv4 address space to
               some degree.  Since they could all do this, with
               potentially smaller chunks than BGP can do (256
               addresses at present) I think they are all capable
               of making a big difference to IPv4 utilization and
               therefore to make a significant contribution to the
               IPv4 address depletion problem.

(This won't solve the problem - just extend it to give more time for
IPv6 or some other alternative to become attractive and widely used.
Alternatively, it will enable more of us to bury ourselves more
deeply entangled in IPv4 and so make the prospect of something else
even more unthinkable!)


[Q16]

What is the business case for the proposal's mechanisms for
supporting communication between hosts in upgraded and non-upgraded
networks?

  APT        No explicit business case, I think, other than general
             benefits due to APT.  I am not quite sure how it
             works, but I think networks in APT islands have all
             their border routers advertising prefixes to the BGP
             system which cover APT-mapped EID prefixes of end-user
             networks which use ISP networks inside the island.
             So what traffic flows where, and why should one ISP
             carry and advertise to non-APT networks for traffic
             which will be sent to another ISP for that second ISP's
             customer?

  Ivip       For the business case for RUASes deploying OITRDs:

                "Open ITRs in the DFZ" (OITRDs), formerly "Anycast
                ITRs in the core"  2008-03-21
                http://psg.com/lists/rrg/2008/msg00937.html

  LISP-NERD  "Proxy Tunnel Routers" - there has been no discussion
             of the business case for these in NERD specifically.

  LISP-ALT   Recent long discussions in the RRG seem to indicate
             the LISP designers have no business case in mind for
             "Proxy Tunnel Routers":

               http://psg.com/lists/rrg/2008/msg00963.html
               http://psg.com/lists/rrg/2008/msg00965.html

             As far as I know, the alternative - LISP-NAT -
             won't work.  See my critique of LISP-NAT on
             2007-12-01:

               http://psg.com/lists/rrg/2007/msg00674.html

  TRRP       I don't recall the details right now, but
             http://bill.herrin.us/network/trrp-implementation.html
             mentions various carrots and sticks.


[Q17]

Where are ITRs placed?


  APT        Default Mappers are in ISP networks, perhaps at
             border routers if I remember correctly.  All other
             ITRs are caching ITRs and I think they can be located
             at Provider Edge routers, or is it Customer Edge, or
             both, or in other places too?

  Ivip       OITRDs in the DFZ.  ITRs can be pretty much anywhere
             in provider and end-user networks, as long as they
             have an ordinary ("RLOC" = public, stable, conventional
             BGP managed) address.  Also, ITFHs in sending hosts
             with such addresses.

  LISP-NERD  } PTRs in the DFZ, and ITRs where?
  LISP-ALT   }

  TRRP       I am not sure - I guess in provider and perhaps
             end-user networks.


[Q18]

Where are ETRs placed?

  APT        The same devices as ITRs? (Not counting Default
             Mappers, which are ITRs too.)

  Ivip       ETRs can be pretty much anywhere in provider and
             end-user networks, as long as they have an ordinary
             ("RLOC" = public, stable, conventional BGP managed)
             address.

  LISP-NERD  } ETRs are generally in the same devices as ITRs
  LISP-ALT   } except PTRs?

  TRRP       I am not sure - I guess in provider and perhaps
             end-user networks.


[Q19]

Does the internal routing system of ISP networks need to know about
each end-user network's micronet (EID prefix)?  In other words, can
an ETR in an ISP network put out raw, decapsulated, traffic packets
it receives from an ITR and expect the internal routing system to
take these packets to the proper destination?

  APT        ?

  Ivip       No.  ETRs need some kind of explicit link to get their
             decapsulated packets to the destination.  This could
             be a physical link, or a tunnel of some kind.
             (TTRs are special ETRs for mobility which do this via a
             2-way tunnel established by the Mobile Node.)

  LISP-NERD  } ? I guess so.
  LISP-ALT   }

  TRRP       ? I guess so.


[Q20]

Does every packet addressed to a micronet (EID prefix) have to go
through an ITR and an ETR?  If the answer is No to this question,
then it means that the proposal expects packets to be delivered to
the correct ETR not just by the map-encap scheme, but also by the
local routing system of any ISP network which is configured to have
the end-user's prefix in its local routing system.  Where two ISP
networks have ETRs for the one end-user network, and they rely on
the internal routing system to deliver raw decapsulated packets from
the ETR to the proper point which links to the end-user network,
then each such ISP must have the micronet / EID of the end-user's
network in its internal routing system.  For consistent operation,
this means the internal routing system needs to perform the same
functions as an ITR, including deciding whether this ETR is
reachable and has a connection to the end-user network (and if not
so, then tunneling the packet to another ISP's network and its ETR,
which requires an ITR function).

  APT        ?

  Ivip       Yes.

  LISP-NERD  } ?
  LISP-ALT   }

  TRRP       ?


[Q21]

What is the source address of the outer header of the packets in the
ITR-ETR tunnel?

  Ivip       Sending host's address.

  APT        } ITR's address.
  LISP-NERD  }
  LISP-ALT   }
  TRRP       }


[Q22]

Following the above answers, can the sending host traceroute through
the tunnel?

  Ivip       Yes, with a somewhat modified traceroute program.  This
             would also be able to identify the ITR and ETR.

  APT        } No, unless the ITR did heroics to convert the ICMP
  LISP-NERD  } messages it receives into ICMP messages with the
  LISP-ALT   } correct data for a standard or modified traceroute
  TRRP       } program on the sending host to recognise.


[Q23]

Following the answer about outer source address, how can an ETR
perform the same filtering on packets it decapsulates as an ISP
border router might perform on packets coming into the ISP network -
specifically, rejecting any packets from outside the ISP network
which have source addresses matching any internal prefix of that
network?  See note below my signature for more on this.

  Ivip       The ETR simply rejects any inner packet which has a
             different source address than the source address
             of the outer header.  See "ETRs checking src & dest
             addresses", RAM list, 2007-07-12:

http://www.ietf.org/mail-archive/web/ram/current/msg01691.html

  APT        } The ETR would need to do a complete, expensive,
  LISP-NERD  } filter operation on the inner source address
  LISP-ALT   } against whatever list of prefixes the ISP's
  TRRP       } border routers use - which could be huge in a
               large ISP network.

[Q24]

To what extent would packets be delayed when the ITR has no mapping
for the micronet (EID prefix) it is part of?  (Not counting
occasional failures due to lost packets in local networks.)

  APT        Very short - a few 10s of milliseconds I guess, since
             all caching ITRs send their packets to a local Default
             Mapper, with both tunnels the packet to the correct
             ETR without delay, and sends back an ETR address for
             the ITR to use.  (Does the map reply include a
             specification for the EID prefix, so the ITR doesn't
             have to ask again when it gets a packet for a nearby
             address which is part of the same EID?  If so, then
             this is good in many ways.  But if so, then how well
             will load sharing work, since the ITR would send
             all its packets to the ITR nominated by the Default
             Mapper?)

  Ivip       No delay if the ITR is an ITRD.  Very little delay
             if it is an ITRC.  This depends on how close the
             nearest QSD is, though a QSC may have the mapping
             and respond without having to ask an upstream QSD.
             A few 10s of milliseconds I guess.  However, caching
             ITRCs in the same rack as QSDs, connected by an
             Ethernet cable or two, will get their mapping in a few
             milliseconds.

Apart from potential trouble with NTP packets (which could be fixed
by the NTP client sending an initial packet to get the ITR up to
speed, and then a timing-related packet a few seconds later), I
think both APT and Ivip would involve initial packet delays which
are firstly "no problem" for end-users and secondly so low that it
would be unlikely for them to be credibly trumped up into something
which appears significant to end-users, by some anti-APT or
anti-Ivip marketing campaign.

  LISP-NERD  No delay.

  LISP-ALT   Significant delays due to the global nature of the
             query system - fractional second at worst.  PLUS
             a significant risk of a long delay due to the
             possibility of the request or reply packets being
             dropped.  PLUS an often much longer delay in the ALT
             network than would be indicated by geographical
             distance due to ALT's insistence on strong
             aggregation.  See: "ALT's strong aggregation often
             leads to *very* long paths" 2008-01-28:
             http://psg.com/lists/rrg/2008/msg00229.html and the
             long discussion which followed.  The closest thing
             to a defence against this critique was Scott's
             message "Re: Why delaying initial packets matters"
             2008-03-04: http://psg.com/lists/rrg/2008/msg00584.html
             and my response to this towards the end of:
             http://psg.com/lists/rrg/2008/msg00791.html

  TRRP       Significant delays due to the global nature of the
             query system - fractional second at worst.  PLUS
             a significant risk of a long delay due to the
             possibility of the request or reply packets being
             dropped.  PLUS often longer delays due to the need
             to perform recursive DNS queries.  See: "Delays
             inherent in TRRP's DNS-like lookup?" 2008-02-28:
             http://psg.com/lists/rrg/2008/msg00450.html and
             the discussion which followed.


[Q25]

Does the proposal have an alternative system for delivering packets
to ETRs for which the ITR currently has no mapping?

  APT        No - the caching ITR or the Default Mapper always
             has the mapping.

  Ivip       No - the packet is always handled by a full database
             ITR or a caching ITR which has a reliable, close
             full database Query Server.

  LISP-NERD  No - all ITRs are full database.

  LISP-ALT   Yes.  The ALT network delivers the packet to the.
             correct ETR, where it also functions as a mapping
             request.

  TRRP       Yes - Waypoint Routers.  But see my critique:
             http://psg.com/lists/rrg/2008/msg00475.html



I may think of other questions and answers and post them in later
messages.

I think all these questions are instructive in helping us understand
the commonalities and differences - and the strengths and weaknesses
- of the various proposals.

I think these questions help us build a taxonomy which will help us
better understand the problem and solution spaces.

  - Robin           http://www.firstpr.com.au/ip/ivip/



Note on filtering of source addresses:

Even if the end-user runs their own ETR, the ISP - or ISPs - who
provide connectivity are likely to want to ensure there is some
source address filtering on the decapsulated packets.

Without the map-encap scheme, the ISP can filter at its border
routers and so prevent any attacker (implicitly, attackers are
outside the ISP and end-user network) from sending packets into
either network with the source address spoofed to be an address
inside the ISP network.

Since it is improbable that any ETR will have the grunt to do source
address filtering on decapsulated packets according to a long list
of prefixes in the ISP's network (except in the case of Ivip, which
does it automatically, with minimal effort and without having to
know the list of prefixes to filter), the other map-encap proposals
would lead to the end-user network being wide open to packets with
spoofed source addresses.

An attacker could send a packet from anywhere to the ETR and the
decapsulated packet could have the source address of any host in the
ISP's network.  This is likely to be a security concern, if only
because an attacker could prompt the destination host to send
packets to the host at that spoofed address.

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg