[RRG] Taxonomy: 25 questions
Robin Whittle <rw@firstpr.com.au> Wed, 02 April 2008 00:04 UTC
Envelope-to: rrg-data@psg.com
Delivery-date: Wed, 02 Apr 2008 00:04:57 +0000
Message-ID: <47F2CD78.2010806@firstpr.com.au>
Date: Wed, 02 Apr 2008 11:04:08 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Routing Research Group <rrg@psg.com>
Cc: Lixia Zhang <lixia@cs.ucla.edu>, Scott Brim <swb@employees.org>, Philip Eardly <philip.eardley@bt.com>, Louise Burness <louise.burness@bt.com>
Subject: [RRG] Taxonomy: 25 questions
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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
- [RRG] Taxonomy: 25 questions Robin Whittle
- Re: [RRG] Taxonomy: 25 questions William Herrin
- [RRG] Re: Taxonomy: 25 questions Lixia Zhang
- Re: [RRG] Re: Taxonomy: 25 questions Robin Whittle
- Re: [RRG] Taxonomy: 25 questions HeinerHummel